Will This Economy Finally Push the Toyota Way Into Software Development?

Next Story

Fear Kills Businesses, Dead

This summer, I worked under marketing thought-leader Seth Godin. I’ll never forget his quote about innovation: “Creativity thrives under constraints.”

Last spring, I spent a week shadowing one of the world’s top lean manufacturing experts–a Japanese sensei who had worked under Taiichi Ohno. The lean manufacturing movement began when the Japanese realized they couldn’t directly compete with Detroit. So they innovated the car manufacturing process. Their success is evident.

Gradually, concepts from the Toyota Way permeated all manufacturing industries. But only now is it starting to hit mainstream knowledge management process–like software development. Wikipedia calls it “Agile Software Development.”

Certainly, moving to Agile isn’t pain free–there is risk involved–but companies that take the risk consistently report strong results, including those listed on the banner above. (Expect it to be flavor of the week if you apply it like the flavor of the week.)

On Friday, I interviewed Ryan Martens, CTO & founder of Rally Software, about agile development. (Rally offers Agile lifecycle management products and is a key player in the online Agile development community.)

Ryan told me that approximately 30-40% of ISV’s have begin experimenting with Agile practices, but it’s only penetrated 10-15% of major enterprises. Enterprises typically use success metrics oriented towards cost, rather than time-to-market.

If you want to experiment, Rally recently created an ROI calculator based on previous client work. Some of it feels like smooth marketing, but there’s also a few gems about the radically different paradigms in Agile development.

I wonder.
If Seth’s quote implies Agile adoption rates will skyrocket in the face of a tanking economy.

  • AgileWTF

    Agile is a load of crap. Macros repackaged with a buzz-word to lure idiots.

    • AgileFTW

      Bitter, party of 1, your table is ready.

      • .

        Youre welcome to join me..

      • Voice of Reason

        stupid peoples.
        your all acting like children.

  • http://www.z-portal.uni.cc Eleclion

    Great. Now what in the world does “Agile Development” mean in the first place? Sounds like more management jargon to me.

    • bob

      Check out the graphic closely! Ah, what irony.

      “Rally customers are 1/4 the number of defects” !
      Rally customers are defects?

      So with Agile, you reduce your error rate, and apparently you demonstrate that by either:

      a) having an error in your Post-It Note graphic (one in three Post-It notes is an error. Seems like a high error rate to me. (Especially if it’s 1/4 the old way, which would be an astonishing 4 in 3.


      b) you call some portion of your customers “defects”.

      • http://lab209.com/ lab209

        Very interesting observation!

        I missed it the first time round.

        Treat customers as defects….hmm..is that a new management paradigm now? ;-)

  • http://www.z-portal.uni.cc/ Eleclion

    Dilbert: We need 3 more programmers.
    Boss: Use agile programming methods.
    Dilbert: Agile programming does not mean doing more work with less people.
    Boss: Find me some words that do mean that and ask again.

    • http://buzvia.com/woodmarvels.com Jon

      Hahahaha… that’s great “Eleclion”

      Software that works is software that works, no matter the framework or terminology used. Names sound great but it’s what you got under the hood that is really the most valuable asset.

      http://WoodMarvels.com – Create Unique Memories

  • nemrut

    “Creativity thrives under constraints.” great quote as too little constraints equal to ‘analysis paralysis.’

    I’ve always done my best work under clearly defined constraints…

  • http://www.scissor.com/ William Pietri

    There is no denying that a bunch of people are eagerly marketing packages of moonbeams and bullshit and calling it “Agile”.

    However, that’s a problem with anything that becomes popular enough to become a fad. The question is: is there anything to it?

    A great example is object orientation. Initially, nobody did it. Then it was a niche item for a while, where a lot of people had a lot of success with it. Suddenly, it was a giant trend, and pretty much every mainstream language ended up providing at least some support for it. Eventually, it became the default, and now you have to argue hard to use a language that doesn’t support OO development.

    Of course, that doesn’t mean that everybody is getting the value out of OO that early adopters did. There is a lot of cargo cult object orientation, where people write effectively non-OO code in OO languages, perhaps putting a dubious icing of misapplied design patterns on top.

    I think it’s the same thing with Agile. As a developer, using Agile techniques has made a big difference for me in increased productivity, higher quality, and much lower stress. And as a startup guy, I firmly believe that it is negligent in that context to to use anything other than an Agile-style approach, where you release early and often and continually gather and react to user feedback and real-world usage patterns.

    So I believe there is something to it. However, if somebody is thinking that adopting an Agile tool or starting to use some Agile buzzwords will make a big difference, they’re 100% wrong. As with Toyota versus Detroit, it is difference in core philosophy. If Agile adoption doesn’t affect the heart of your operation — and from there, how you do many things — then it will be just another fad, a distraction from getting real work done.

    • Huh?

      Who the F are U and your personal ‘agility’? I never knew you could be ‘personally agile’? Oh wait, maybe I do but its in a diffrent franchise. You wanna go pipe hitting w. me? Grow some balls so i can kick em in and ill dust you off and pat you on the back and say ‘Welcome to my world!’

      • Mark

        Thanks for providing honest and valuable discourse in this thread. You are a moron. Go back to you MySpace world before someone finds out you are in the real world and someone carries the weight to knock you back to next week.

  • Name

    Whatever “Agile” was, when MBAs start to embelish their resume with it, it will be killed.

  • http://www.datacenterjunkie.com/ Michael T. Halligan

    Quick historical side-note, Japan’s dominance in manufacturing stems largely from Theory-Z, which itself stems back to a manufacturing process philosophy named Total Quality Control, or TQC. TQC was the brainchild of William Edwards Deming.

  • http://anon anon

    TC – I guess you need to do something about Huh? type abuse. Totally offensive.

    • Uh


  • http://www.allurefx.com Sekhar Ravinutala

    Salesforce switched lock-stock-and-barrel to Agile couple of years back. They’re very happy with the results and even wrote a whitepaper on the process – check out http://wiki.apexdevnet.com/index.php/Agile_Development_Meets_Cloud_Computing. I think Agile works especially well when the development cycles are short and the requirements are shifting.

    • http://www.jobstaxi.com Yasser

      I agree with this 100%, it will work under certain circumstances, just not most.


    • thinkpositive

      With Salesforce.com there software runs on Google technology which all they do is write a bunch of widgets and components in Python. The libraries to these codes are already been created and therefore they can easily repackage or recreate certain features in their apps at a moments notice.

      I think agile is perfect for web-based services like salesforce.com. I also think agile fits well with the open source community. But if your locked down in jobs with many moving components and have various teams working of the projects, agile just won’t cut it.

      I like the sound of agile. Its a very catchy buzzword. But in my opinion a good team that does the waterfall method can do just as well as the same team that implements the agile method.

      • NotAChance

        “…Salesforce.com there software runs on Google technology…”

        Salesforce.com does not run their software on Google technology. And the rest of what you stated about Salesforce.com is all wrong.

  • http://bluetooth-pairing.com warren

    “Agile Development” only mean some management thought, it is not so easy to implemented.

  • BJ Clark

    Wow, these comments are almost as good as youtube.

  • Nick

    To Anyone that is interested in reading about Toyota and their mindset “The Toyota Way” by Jeffrey Liker is a good place to start

  • http://cromotion.net Berislav Lopac

    The problem with agile is that it is not a development method, it is a mindset. As such, its benefits are not clearly visible at first, especially to managers stuck in their traditional ways of “this is how it’s always been done”.

    • http://rallydev.com Hubert

      Very right – it is a mindset. The benefits are visible very quickly though, when you give the folks on a dev team the power to organize their own work they will immediately respond positively. They love it, no more project manager telling them what to do. Management benefits take longer, you’re right about that. But not that long, just a month or two before it becomes visible that a better product is being developed.

  • Chris

    “Some of it feels like smooth markeitng”

    A. You spelled marketing wrong, and you are the author.

    B. I hate to tell you guys this, but this is 1% programming and %99 marketing.

    All professional software groups use product cycles and QA.

    • http://rallydev.com Hubert

      Sure – as does agile. It pulls QA forward, to the point where QA is the start of the dev cycle, not the end (when they get squeezed and release ‘known bugs’).

  • Chris

    Next Rally is going to tell us they invented Unit testing.

    • http://www.rallydev.com Ryan Martens

      What we are telling you is that a firm benchmarked a bunch of our customers against a database of 7500 projects and found these results. We provide coaching, training, hosted solutions and a community of support for folks interested in adopting agile. We did not invent any of this, we are just very good at helping teams and companies that are interested in doing it on teams who are typically large and distributed.

  • Chris

    and that they also invented ISO9001

    • http://www.rallydev.com Ryan Martens

      Mary and Tom Poppendieck do a great job of describing the direct linkage from lean to agile in their book “Lean Software Development.” Give it a try as she comes from a the 3M world. Agian, no claims on ISO 9001:)

  • http://www.kongregate.com Jim Greer

    Whether you like buzzwords or not, developing in short cycles works better for most projects than writing huge design docs and then building for a year. It’s worked well for Kongregate.

    What didn’t work well was Rally itself. We used it for about 6 months and it was bloated, hard to use, and expensive. We switched to Pivotal Tracker and have been very happy with it – much simpler, much easier to use, and much cheaper.

    • Chris
      • http://www.kongregate.com Jim Greer

        No thanks!

    • http://www.rallydev.com Ryan Martens

      We now have two editions of our product. A Community Edition that is free for teams of 10 or less and our Enterprise Edition that supports larger and typically more distributed teams. (See the web site for the comparison – http://www.rallydev.com/products/lifecycle_management/)

      Our largest customers have 1000’s of developers spread around the world coordinated in 100’s of small 10 person teams producing some very large and mission critical software systems. The Enterprise product is built to manage the requirements backlog prioritization process, program status roll-up, the system acceptance testing and the integration into other software tools in the process including developer IDE’s, build systems, case management and automated acceptance testing. The Community Edition is built for small teams just getting started and does not include the quality, integration or large scale program management capabilities that may have been more that you were looking for.

  • JV

    I’ve been on an Agile team for the past year and half. I work for a very large health care organization and we were the guinea pigs for the move to Agile. I can tell you that working on an Agile team while the rest of the organization is in Waterfall or whatever you want call it is a painful process when you need the services and/or time of outside resources. However, within the team, the Agile process has been a liberating one. As the name suggests, we’re much more flexible when problems arise and the team is almost always aware of the goals and milestones of the project, much more so than in other teams I’ve worked on.

    Of course, there are problems with Agile, scope creep being the main one I’d say. But overall, I’ve enjoyed working in this methodology. Sure, it’s a buzzword and sure, some people will either misunderstand and/or abuse the term. And I wouldn’t say it’s appropriate for every project or organization. And there are Agile purists, like the Rally people, who’ve been hired by my employer as Agile consultants, who take it too far. But in my experience, it can work well in small teams who are expected and required to release frequently.

    That’s just my opinion. There are a couple people on my team who absolutely hate Agile. Can’t please everyone.

  • http://iconbuildings.com David Thomas Garcia

    Using an agile process in software development is about being adaptive to the situation at hand. Since the economy just took a sudden swing from great to horrible, it will be software developed with agile processes that can change their requirements to fit the new business needs. Marin Fowler wrote an excellent piece on agility in software several years ago: http://www.martinfowler.com/articles/newMethodology.html

    The big difference in typical software development (waterfall method) and using agile processes is that the former relies on up-front, monolithic requirements whereas the latter focuses on short intervals. You would think that having everything planned up-front is better, in theory it results in a well designed system. In practice, however, it is impossible to know what will be needed by the time the software is complete. For example: the economy failing. Even without such an event, by the time software developed with the waterfall method is complete; the requirements are obsolete making years of software development worth much less than it’s potential. Not to mention, the software during the development process probably was not available for production use.

    An opposite example using agile processes: home-grown CRM software my company developed for internal use. After just six weeks we had a deployed software package that every department in our company was using. Every week since then for the past two years has focused on new ideas that help our company do business better. What if instead we decided to plan a 1000 feature software package upfront? Based on my past waterfall experiences, I think I would still be working on it and we would not have spent the past two year dominating the market.

    I’ll leave you with a quote from Gary Hamel from Harvard Business Review Sept 2003
    “To be resilient, an organization must dramatically reduce the time it takes to go from ‘that can’t be true’ to ‘we must face the world as it is.'”

    • Chris


      OMFG, you’re on .NET and windows server
      You need all the help you can get!

      I think product cycles should be tailored to each company, but sometimes people really need to read a manual to get things done.

      • http://iconbuildings.com David Thomas Garcia

        Java, C#, PHP, to each his own for development. All are mature and viable options, the best for the job depends on the experience and taste of the developers. For my project C# was a great fit since 5 years worth of legacy code was already written in C# which made the choice of platform very easy. The need for a seamless offline experience and a desktop version ruled out PHP, an otherwise choice.

        More important than the choice of technology is the way the team works together. I would even argue that the people and management in the project is even more important to success than choosing an agile vs waterfall technique. I’ve previously worked with developers whose response to a problem is a list of all the reasons it will never work rather than all the ways it can be done. That attitude doesn’t help productivity in any situation.

      • Chris

        Google gears…

      • Chris

        “I’ve previously worked with developers whose response to a problem is a list of all the reasons it will never work rather than all the ways it can be done.”

        Developers have to manage the expectations of the account managers as well as the code.

      • tom

        Just use the right tool for the job and be done with it moron…

  • Wade

    I agree with the first comment. The Agile movement is 90% marketing, designed for the career acceleration of the 1000 people that claim to be experts on it. And the practitioners are just wannabe, kiss-up, sell-outs.

    But you if you have a agile job, call me !

  • thinkpositive

    Sorry Im not a fan of agile. Its nothing more than one of those project management buzzwords that sounds catchy but its nothing more than a development process. Sure quick and fast deployment of software is great. But why switch to it when the waterfall method is the standard for the way software apps are written.

    I think its just one of those things that a high paid project manager learns about in school and makes him sound smart and therefore he is obligated to demand higher wages.

    Just about every software development company I know is not moving to this style of development. Why should they? Whatever works for them works and therefore it will cost more just to implement a process to satisfy CEOs of Fortune 500 companies.

    Agile is only good if you have hardcore coders that can change a certain feature of the app within hours rather than days. But if you rely on coders who have to consistently pull out the C# Bible to look up various libraries than your best bet is stick with Waterfall and there is nothing wrong with that.

    • jeffrey

      Waterfall method may be the standard for writing apps, but does it work? Do clients like waterfall? Does all that documentation add any value to the project? In my experience, most clients want less docs and faster releases.

      Waterfall methodology was stolen from best practices used highly in manufacturing processing. Problem is, software dev is not manufacturing. Software Dev is very dynamic and each project is unique in it’s output.

      Agile enables a team to produce smaller results quicker rather than waiting for the entire dev cycle to complete. By engaging your product owner (client) on a daily basis, you minimize the risk that req’s stated up front will not meet customer expectations. Also, throw in the idea of “self-directed teams” and you enable the entire Agile team to have a say in how the project is delivered vs. the standard, dusty MS Project plan.

      If used properly and accepted by stakeholders and management, agile can be very helpful for project delivery and customer satisfaction.

      • http://rallydev.com Hubert

        Hmm, did you know that the Empire State Building was built in 9 months, with little design upfront? Design for each floor was done 4 weeks before building the floor, with an average speed of 2-4 floors a week? Very agile. The same is true for most manufacturing processes. No process is predictable anymore, so you need self inspection to create a good and safe process. Whether you’re building a chemical plant, a car factory or software.

      • thinkpositive

        Hi again. Thanks for responding and your argument is logical.

        My thoughts are that the problem doesn’t lie with the process or method. It lies with the team.

        With the agile method you need a very good team of programmers that can write clean code in a flash. What if you have someone that is new to your team and hasn’t done a lot of programming?

        I think that its really not a big priority which method is being used. But the importance is that you have a good team that can do the work fast and good. Thats why I’m just not that impressed with the agile method (yet).

      • giglioraninomicon

        Hubert — comments like that about the Empire State Building (or other construction comparisons) always make me laugh. They are so agile because they didn’t decide how to subdivide the square for each floor until the last minute! Amazing!

        In reality, you don’t get easy-to-implement changes during dev, you get the equivalent of:

        “Can we make the next two floors entirely aquariums?”

        “Can we make the next floor have 10x the square footage, and the one after that needs to be round and half the size of the others.”

        Etc… analogies like this simply do not make sense.

  • http://www.qbalsoftware.com kramer

    You could put some of these Japanese companies in any model and they’ll out perform most. Its not Agile that is giving them their success, its their discipline, attention to details and their process tolerances. They would succeed in under many models. Same goes for software teams I’ve worked on that execute and deliver on schedule. It had little to do with the model.

    I’ve stated to blog a little bit about this stuff, my thinking is agnostic on the status-quo models.


    • thinkpositive

      Speaking of Japanese one of the major factors on why they do so well in manufacturing is not because of any gimmick, theory or even a method.

      My opinion on why they do so well is because of the competition and that they take it personally when their company is behind.

      If our coders (especially those that linger in Redmond) would go and live in Banglador, India or China and try to compete with their IT people I think you’ll see a lot more Americans working harder and faster and doing better coding.

      We just need better competition on whatever we do. I lived in Japan and they consistently compete in everything – from drinking, singing karaoke, car racing (yes, like Fast and the Furious), and arm wrestling, etc.

      Its in their blood to compete. They don’t take defeat lightly and maybe we should do the same here in our country.

      Here at home when we talk to an associate or colleague we tell them “take it easy, don’t work too hard.”

      In Japan they say to each other “gambatte kudasai” which means please work hard.

      See what I mean.

  • http://www.jeffwidman.com/blog/ Jeff Widman

    Fascinating comment threads–sounds like I touched a nerve. Def appreciate hearing more details on actual experiences–both positive and negative.

  • http://www.iterating.net NicolasV

    Jeff, to my knowledge the Agile movement has nothing to do with Toyota or the Japanese. It may be a good marketing analogy for the Rally guys in these days of Detroit trouble, but some basic fact-checking on wikipedia will get things straight.

    As for Kramer’s comment “You could put some of these Japanese companies in any model and they’ll out perform most”, that’s an 80s piece of thinking that was shattered when Franco-Lebano-Brazilian star Carlos Goshn when to save nearly-bankrupt Nissan.

    • http://www.rallydev.com Ryan Martens

      The Detroit story is clearly what some software organizations are facing. You can think of Lean/Agile as a change in Guiding Ideas, Methods, Tools and Infrastructure that some will get and others will not. See Wikipedia on Lean software development for backgrounds and linkages of Agile and Lean. http://en.wikipedia.org/wiki/Lean_software_development

  • http://www.fabianschonholz.com Fabian Schonholz

    I have been using what is NOW called “agile” for many years – at least 12. The problem is the tendency for over engineering that programmers exhibit and the lack of buy-in from upper management into the concept of continuous re-factoring. These two problems have been my worse enemies, as a programmer – when coworked over engineered and affected my development progress – and as an executive as my peers in marketing and buzdev, together with me, negotiate for competing priorities.

blog comments powered by Disqus