Some time ago I posted about the commodification of the IT project manager both on this 
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Is Scrum becoming the McDonalds of Agile? Good or bad?
|
This will even effect the new kid on the block, namely Agile project management. I found this interesting post from the Agile @ Adobe blog posted by Peter Green, in which he argues that Scrum is becoming the “Model-T” of Agile:
I started wondering: “Is scrum too much of a sacred cow to evolve?” I’m not sure the answer to that question, but while thinking about it, the idea came to me that Scrum is not a sacred cow as much as it is the Model-T of agile.
Ford didn’t invent the automobile, that honor goes to Nicolas-Joseph Cugnot, Gottlieb Daimler, Carl Benz, or Wilhelm Maybach, depending on the book you’re reading. What Ford did was figure out a way to mass produce the automobile and sell it to the public at an affordable price such that it became an integral part of the lives of nearly everyone on the planet today.
Similarly, Jeff Sutherland and Ken Schwaber didn’t invent agile. The ideas of agile go back to at least the 1950s and probably before that, and are part of a family of new approaches to doing business that also includes movements like Lean, Theory of Constraints, and Six Sigma in manufacturing, Leadership Agility and Radical Management in management theory, and Lean Startup and Innovation Games for learning about customer needs. What Jeff and Ken did was figure out a way to mass produce Agile and sell it to the software industry in a way that has put agile on the map all the way up the C level of nearly every organization where software is important. Gartner famously predicted that by this 2012, 80% of software development will be done with an agile approach. The focusing of agile principles into a broadly applicable framework like scrum was a major innovation, just as the development of the Model-T assembly line was a major innovation in manufacturing
I have to agree with much of this assessment, and the irony is not lost on me that he is comparing Scrum’s evolution in terms of the Model-T assembly line process. Much of Agile’s initiative was a reaction to the top down, waterfall cum assembly line like process of traditional project management, that while innovative and disruptive from its inception, really is now common place and I have to say, becoming a commodity.
With the mass adoption and churning out of Scrum certifications, which even now has been incorporated into the repertoire of PMI’s certification curricula after initially ignoring the movement, it has now become quite the McDonalds of Agile movements.
So I think we can now ask the question posed by Peter Green:
The Ford assembly line was the exact innovation needed in its day. It persisted as the primary innovation in the auto industry until the 1970s when companies like Toyota evolved a newer approach that was more fit to customer’s evolving needs and provided higher quality products. It took decades for Ford to adopt similar approaches to catch up to Toyota. The question for me is this: at 20 years old, will Scrum see the need to evolve, and if so, how?
What will be the next evolution or revolution of Agile?
|
Posted on: December 15, 2012 11:25 AM
| Permalink |
Comments (2)
The KCP: Kanban Certified Professional
|
Here’s a description of the certification from the LKU site:
Lean-Kanban University (LKU) announces the launch of a professional designation for people coaching Kanban: Kanban Coaching Professional, or KCP. The Kanban Coaching Professional program has been established in response to demand from the community. Since the successful launch of the Lean-Kanban University Accredited Kanban Training program in early 2012, many prominent members of the Kanban community have expressed a desire to be recognized with a professional designation for their coaching, consulting, or managerial contributions. It was felt that Lean-Kanban University should do more than just recognize those offering formal Kanban training…
Candidates for the KCP designation must have completed a 3-day Advanced Kanban Masterclass, developed field experience working with Kanban in one or more organizations, and must submit to a peer review process. The advisory board will appoint a review panel to consider each application.
The Kanban Coaching Professional designation indicates that an individual is a member of the Lean-Kanban University Kanban Coaching Professional program. An annual membership fee will be levied. To maintain their status, KCP’s will be expected to play an active role in the Kanban community. Specific requirements will be advised via the Advisory Board from time to time.
Pawel Brodzinski, a well known blogger on software project management who has expressed an antipathy towards most PM certifications, felt compelled to obtain the certification and expresses his rationale for obtaining it:
As Kanban gets more and more popular, I see more people jumping on this bandwagon, offering training, coaching and what have you. The problem is that sometimes I know these people and I’m rather scared that they are teaching Kanban.
Not that I want to forbid anyone to teach Kanban, but I believe we arrived to the point where we need a distinction. The distinction between people who invest their time to keep in touch with the community, attend events, share experience, engage discussions, etc. and those who just add a Kanban course to their wide training portfolio because, well, people want to buy this crap.
This is exactly why I decided to get enrolled in the KCP program. For this very distinction.
I believe that, at least for now, it differentiates people who you’d like to hire to help you with Kanban from those who you can’t really tell anything about. This is where I see the biggest value of KCP. I really do hope it will stay this way.
I can understand this rationale, for as a similar person who writes about, coaches, consults and trains on topics related to project management I’m always trying to stay on top of these things to add some legitimacy to my background. And of course, I’m unashamedly doing this to increase my profile which increases my ability to earn more by monetizing my services.
If this is something you are looking to pursue in depth, it might be worthwhile to look into this as it is so new and is just on the cusp of the Kanban hype bandwagon that has dawn upon us in the project management world.
|
Posted on: December 01, 2012 04:20 PM
| Permalink |
Comments (3)
Shipping software at 20% completion
|
 I just read this very interesting article from The Economist about two very innovative game companies from Japan called DeNA, which has become famous for an addictive game called “Blood Brothers” and its rival GREE. They’re both mobile game companies that allow you to download their game to your smartphone or tablet for free, but charges for add-ons that increase your chances of winning.
Combined they have posted revenues that has already exceeded Facebook and unlike the game company Zynga famous for Facebook games such as Farmville, are turning serious profits (DeNA made 20.4 billion yuan last quarter which will exceed all of Nitento’s yearly profits this year alone).
Most interesting for us as Agile project leaders is their model of production deployment:
The secret of their success, they say, is their head start in Japan thanks to fast mobile-phone networks that made it easy to play games while commuting, or during spare moments. By studying their customers, they learned a lot. DeNA, for example, found that the average user played for seven minutes, five times a day. So casual gamers need shorter, punchier games than do hard-core gamers who goggle at big screens for hours at a time...
DeNA first puts out its games on browsers rather than applications, which allows for “tweaking and tuning” in real time, says Mr Moriyasu. A Japanese game may be only 20% completed when it is made available to gamers. Its developers believe this enables them to finesse it, so that it stays popular for longer.
So going by Agile standards, they probably run a iteration or two when the game is at a “potentially shippable product” state then deploy and constantly tweak the game based on tracking and customer feedback all the while generating revenue from add-ons that allow customers to continue on with the game.
It has become so addictive that Japanese regulators are scrutinizing practices such as users being allowed to collect “randomly generated tokens that the regulator likened to a slot machine.”
In any event, this example shows how the mobile gaming industry which is growing by leaps and bounds is pushing the envelope with respect to Agile practices and methods.
The secret of their success, they say, is their head start in Japan thanks to fast mobile-phone networks that made it easy to play games while commuting, or during spare moments. By studying their customers, they learned a lot. DeNA, for example, found that the average user played for seven minutes, five times a day. So casual gamers need shorter, punchier games than do hard-core gamers who goggle at big screens for hours at a time...
DeNA first puts out its games on browsers rather than applications, which allows for “tweaking and tuning” in real time, says Mr Moriyasu. A Japanese game may be only 20% completed when it is made available to gamers. Its developers believe this enables them to finesse it, so that it stays popular for longer.
|
Posted on: November 23, 2012 02:32 PM
| Permalink |
Comments (1)
Scaling continuous integration at Google
| As a follow up to my post on "Continuously controlled integration for Agile development", here's a Google Tech Talk video on using such practices to scale on a massive code base. Here's a snapshot of what's involved:
Even at this size, Google still runs the build from a single monolithic source that has various programming languages intermingled with each other. Here's an excerpt from the talk's introduction:
At Google, due to the rate of code in flux and increasing number of automated tests, this approach does not scale. Each product is developed and released from 'head' relying on automated tests verifying the product behavior. Release frequency varies from multiple times per day to once every few weeks, depending on the product team.
With such a huge, fast-moving codebase, it is possible for teams to get stuck spending a lot of time just keeping their build 'green' by analyzing hundreds if not thousands of changes that were incorporated into the latest test run to determine which one broke the build. A continuous integration system should help by providing the exact change at which a test started failing, instead of a range of suspect changes or doing a lengthy binary-search for the offending change. To find the exact change that broke a test, the system could run every test at every change, but that would be very expensive.
To solve this problem, Google built a continuous integration system that uses fine-grained dependency analysis to determine all the tests a change transitively affects and then runs only those tests for every change.
For those who want to learn more, watch the video below:
At Google, due to the rate of code in flux and increasing number of automated tests, this approach does not scale. Each product is developed and released from 'head' relying on automated tests verifying the product behavior. Release frequency varies from multiple times per day to once every few weeks, depending on the product team.
With such a huge, fast-moving codebase, it is possible for teams to get stuck spending a lot of time just keeping their build 'green' by analyzing hundreds if not thousands of changes that were incorporated into the latest test run to determine which one broke the build. A continuous integration system should help by providing the exact change at which a test started failing, instead of a range of suspect changes or doing a lengthy binary-search for the offending change. To find the exact change that broke a test, the system could run every test at every change, but that would be very expensive.
To solve this problem, Google built a continuous integration system that uses fine-grained dependency analysis to determine all the tests a change transitively affects and then runs only those tests for every change.
|
Posted on: November 18, 2012 05:29 PM
| Permalink |
Comments (1)
The Agile Project Leader's Dilemma
| Read this great article from the NY times by one of my favorite business writers Clayton Christensen. It was written just a few days before the presidential elections in which Obama came out the eventual victor and discusses the dilemma facing our capitalist system which has been experiencing a lethargic interest as of late. As he states: Capitalists seem almost uninterested in capitalism, even as entrepreneurs eager to start companies find that they can’t get financing. Businesses and investors sound like the Ancient Mariner, who complained of “Water, water everywhere — nor any drop to drink.”
It’s a paradox, and at its nexus is what I’ll call the Doctrine of New Finance, which is taught with increasingly religious zeal by economists, and at times even by business professors like me who have failed to challenge it. This doctrine embraces measures of profitability that guide capitalists away from investments that can create real economic growth.
Christensen goes on to describe three models of innovations that investors and executives would typically finance with their capital:
His argument, I think a very valid one, is that the world has been focused almost exclusively on the innovations of efficiency since the start of the recent great recession. But such innovations "also emancipate capital. Without them, much of an economy’s capital is held captive on balance sheets, with no way to redeploy it as fuel for new, empowering innovations. For example, Toyota’s just-in-time production system is an efficiency innovation, letting manufacturers operate with much less capital invested in inventory." The discussion goes on to describe how these innovation movements typically cycle themselves through a normal economic period of growth and recession creating an almost organic like system that regulates itself like a homeostatic organism. But the most scary part of his article is the description of this current economic downturn and how it fits into an overall pattern of being increasingly prolonged:
In the last three recoveries, however, America’s economic engine has emitted sounds we’d never heard before. The 1990 recovery took 15 months, not the typical six, to reach the prerecession peaks of economic performance. After the 2001 recession, it took 39 months to get out of the valley. And now our machine has been grinding for 60 months, trying to hit its prerecession levels — and it’s not clear whether, when or how we’re going to get there. The economic machine is out of balance and losing its horsepower. But why?
The answer is that efficiency innovations are liberating capital, and in the United States this capital is being reinvested into still more efficiency innovations. In contrast, America is generating many fewer empowering innovations than in the past. We need to reset the balance between empowering and efficiency innovations.
So this prolonged downturn has created a perpetual cycle of feeding efficiency innovations to more and more efficiency innovations. I can relate this in real terms as the projects I've been involved with have had "efficiency" as it goal front and central with very little sustaining and practically none of the empowering innovations Christensen outlines.
So the implications are that this is not only a capitalist's dilemma, but a dilemma for the Agile project leader as well. Lean is a great tool that is at the disposal of the Agile project leader, but it is not the only one. Agile is at heart a method that was tailor made for empowering innovations since it allows one to test out and try new innovative products and services, the very ones that will create the new jobs of tomorrow.
Christensen's framework is a brilliant way to view your pipeline of projects and to ensure they are the right mix that will not only create efficiencies and sustain existing products and services, but to empower growth that will propel not only your organization's portfolio of products and services, but you and your team's personal and professional growth.
Some food for thought!
Capitalists seem almost uninterested in capitalism, even as entrepreneurs eager to start companies find that they can’t get financing. Businesses and investors sound like the Ancient Mariner, who complained of “Water, water everywhere — nor any drop to drink.”
It’s a paradox, and at its nexus is what I’ll call the Doctrine of New Finance, which is taught with increasingly religious zeal by economists, and at times even by business professors like me who have failed to challenge it. This doctrine embraces measures of profitability that guide capitalists away from investments that can create real economic growth.
|
Posted on: November 09, 2012 06:31 PM
| Permalink |
Comments (1)