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.
Agile is a load of crap. Macros repackaged with a buzz-word to lure idiots.
Bitter, party of 1, your table is ready.
Youre welcome to join me..
stupid peoples.
your all acting like children.
Great. Now what in the world does “Agile Development” mean in the first place? Sounds like more management jargon to me.
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.
OR
b) you call some portion of your customers “defects”.
Very interesting observation!
I missed it the first time round.
Treat customers as defects….hmm..is that a new management paradigm now? ;-)
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.
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.
Jon
http://WoodMarvels.com – Create Unique Memories
“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…
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.
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!’
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.
Whatever “Agile” was, when MBAs start to embelish their resume with it, it will be killed.
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.
TC – I guess you need to do something about Huh? type abuse. Totally offensive.
<3
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.
I agree with this 100%, it will work under certain circumstances, just not most.
Yasser
http://www.jobstaxi.com
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.
“…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.
“Agile Development” only mean some management thought, it is not so easy to implemented.
Wow, these comments are almost as good as youtube.
To Anyone that is interested in reading about Toyota and their mindset “The Toyota Way” by Jeffrey Liker is a good place to start
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”.
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.
“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.
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’).
Next Rally is going to tell us they invented Unit testing.
Chris,
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.
and that they also invented ISO9001
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:)
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.
http://www.bugzilla.org/
There you go.
No thanks!
Jim,
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.
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.
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.’”
http://iconbuildings.com/community/blogs/webprog/archive/2008/11/20/historyeventargs-could-not-be-found.aspx
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.
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.
Google gears…
“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.
Just use the right tool for the job and be done with it moron…
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 !
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.
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.
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.
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).
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.
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.
http://www.qbalsoftware.com
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.
Fascinating comment threads–sounds like I touched a nerve. Def appreciate hearing more details on actual experiences–both positive and negative.
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.
Nicolas,
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
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.
There is nothing new here to this story. Agile is already in use in many industries throughout the engineering complex. The term “Agile” just refers to an umbrella of processes that all follow a similar pattern of iterative development with small software teams.
Whether it be SCRUM, XP, RAD, JAD, etc. they are all familiar tools for software engineers worth their salt.
Claiming that Agile is the realization of the Toyota Way is drawing a long bow, and the logical leap from Seth Godin’s comment to Ryan Martens’ quite jarring. While Agile does claim TPS (lean manufacturing) as an inspiration and share similar principles, there’s a lot more to the Toyota Way that TPS.
The current economic crunch is more likely to accelerate adoption of SaaS and renew interest in off-shoring, than drive Agile adoption across the enterprise.
Peter,
Clearly this is an AND for companies like Rally and Salesforce where the combination of SaaS and Agile as a very positive effect that eliminate much of the need to outsource. See my MassTechCouncil talk on the powerful combination. http://agilecommons.org/posts/34ab218eaf
Of course outsourcing can be a real bonus. We use GlobalLogic as a partner to implement and manage many of our connector products that are outside our core code base and technology stack. It is great relationship and separation of skills. (they are writing C# connectors to our WebServices)
What we do not do is outsource part of the work. The Development and QA teams are complete teams at GlobalLogic. In addition, their lead act as the product owner proxy to our Integration product line manager. As a result, these offshore teams are mindful of code quality, customer issues and do a great job.
Clearly this is an AND, not an or.
Hi,
Outsourcing is a separate issue to offshore, and seems be increasing driven by limited management bandwidth than cost (i.e. there’s a limited number of balls we can keep in the air at one time, so one option is to get someone else to juggle some of our balls for us.).
r.
PEG
Yeah, TC editors, this article is rather crap. Let’s see: Toyota, Seth Godin, Agile, Taiichi Ohno, the recession, and Rally Software brochureware all wrapped up with a bow.
Phew!
I can see where this article intended on going. Having worked with Toyota and several other Japanese firms, however, I can say their business practices are NOT Agile at all. My observations have shown:
1. Many layers of successive refinement.
2. Refinement taken to the point where any faults are infinitesimal.
3. Very bureaucratic and hierarchical organizational structures.
So what you get are very high quality products, but not a terribly dynamic product strategy. Much of Toyota’s success comes from decades of building a products with really tight requirements: lots of quality and features at minimal cost.
You could have said the same thing about Sony — expertise at miniaturization rooted in their humble portable radio past — but they have recently failed to reorient themselves in a software driven, networked product category. This is where the overweight bureaucracy sets in.
One of the biggest disconnects between this line of thinking and modern software development is that making mistakes is ok. In the freemium web business you are usually rewarded for fast turnaround above quality. For lots of Japanese companies defect (bug) rates are king — either you don’t ship, or you scale back features.
Danb,
There are couple of interviews with Toyota Chief Engineers that would completely agree with your point, they are not agile like software teams. I think this is result of the size and maturity of many of their products. However the Prius story is a good example of the company being able to run much faster cycles when it needs to. http://money.cnn.com/magazines/fortune/fortune_archive/2006/03/06/8370702/index.htm
As you point out, there is a choice to make between where you focus the benefits, zero defects, time to market and productivity. The QSMA case study and Impact Report behind our ROI calculator show that you can have all three. (http://www.rallydev.com/agilevalue/step1/ ) We find most web software companies choose to focus the benefits on Time to Market. Most large embedded developers choose to focus the benefits on quality. In turbulent times like these, many folks are choosing to focus the benefits on productivity. http://searchsoftwarequality.techtarget.com/news/column/0,294698,sid92_gci1340902,00.html#
In either case, we appreciated Jeff’s gift wrapped in a bow for Christmas. Based on my interview with him last week, he is very passionate and deep on the lean topics. It sure started a nice debate:)
The TPS has been incredibly successful for Toyota but one of the things I regularly read when learning about lean at other companies is that they only scratch the surface because they generally just use the tools, such as JIT, rather than embedding the philosophy deep within their culture.
I havn’t done software development for a few years so am not familiar with Agile development but this is perhaps something to look out for.
To the OP though, sounds like you’ve had a couple of great learning experiences there.
Yep–couldn’t agree more.
I remember visiting one of Toyota’s US plants quite a while ago, and the thing that stuck out was the culture rather than the techniques. Line workers arrived at work in the morning looking forward to finding out what had been changed (improved) since they went home. They look forward to change in their work environment–even change in their roles–rather than dreading it like workers in most organizations.
The powerful way about the Toyota Way is this change in culture, not the tools that are used.
How can I mod this article down, or mark it as marketing?
r.
PEG
Adi, there are plenty of companies that do well with implementing TPS style practices and embedding them in company culture, beyond scratching the surface. Check out Danaher, Paccar, even Boeing does lean well in SOME parts of the company (accounting for example). The west coast of the USA seems especially well receptive to lean practices.
On another note, many of the comments made here seem very much like characters in books about implementation of lean, six sigma, or TQC. They’re angry, bitter people who don’t want to adapt to new ways of doing things. After they see a functioning example of the practice in question, they become excited and partake in its implementation. The key to getting them excited however, is meaningful results from people who are championing the process. Lip service from management will never make people see the benefits of a business system. Perhaps some of the negative discussion of Agile here is just coming from people who’s manager’s did not have the insight, results, or tools to change their company’s culture to work the Agile way. Or.. the people complaining could just be CAVE people (Citizens Against Virtually Everything).
This is not a very good article. When you think about all that has been written about ‘agile’ this is a pretty poor summary. The link to Toyota is not developed at all. Hello?
Toyota on track for first-ever loss in fiscal 2009
Japan’s largest automaker revises forecasts to an operating loss of $1.7 billion in year ending March 31…
http://www.marketwatch.com/news/story/Toyota-track-first-ever-loss/story.aspx?guid={FAF8C52E-6DD7-4D
May be Toyota must go agile! and the journalist retire for a moment…
I agree ‘creativity thrives under constraints’ but, too often, in the software world, the problem lies in turning this creativity into a reality. Too many projects fail because of poor methodology. This is where ‘agile methodology’ comes in… even if I think ‘agile’ is more a marketing word than anything. I just blogged on my methodology to develop web application efficiently, I may not be agile in the strict sense but it is sure efficient :)
FFS the Japanease just did starting in 1948 what Deming wanted to do and the US car giants where too short sighted.
I wanted to add one more thought. Generally speaking, software teams do not have “Product Architects”, they have “Architects of Technology”. Whereas many industries have manufacturing engineers and industrial engineers. If we look at a broad range of software houses, the environments used to develop, integration, build, test, and publish are rarely designed from a end-to-end system perspective. The underpinnings of any given software life cycle model can make or break success. Another area that can greatly improve success is the product architecture itself. If the product architecture is aligned with the business model and the way the product is sold, it should be responsive to change, and it should make the process of development, integration, build, test, publish, install, upgrade more efficient too.
I have started blogging a bit about this at. I think that besides the model, a strong focus of the underpinnings of the model, and the product architecture are areas for big big gains.
http://www.qbalsoftware.com
Disclaimer: I’ve known Ryan Martens for several years.
To all the haters: regardless of what you think about agile or Rally, I knew Ryan when it was nothing more than a PowerPoint deck. The amazing thing is, the fundamental business model has not changed since then. He and Tim knew from the get-go what they wanted to build and who would buy it. That’s extremely rare for a startup.
1) For those who hate the word “Agile”: remove it from your vocabulary but proceed working in short iterations within highly motivated teams strongly coupled with your customer – you will be competitive these days
2) I visited Rally when I was in Boulder, CO 2 years ago. I talked to Ryan and other guys on his team. They develop their software same way as they market it to others. That is fair.
3) In java world, for instance, they choose different dev environments: eclipse, netbeans, idea etc. And there’s always huge amount of inspired proponents of each, ready to participate in long-long religious debates. But that’s life. So people use Rally, others use MSP etc-etc.
I think agile and live agile and my team does too. I respect everyone who opposes it either, because they give my team and other teams like mine a competitive advantage. Every opinion should be respected!
I started a software company while clueless about software development (don’t ask…). I hired a few programmers and embarked on my journey. Now, after some 5 years in the business, it appears that we’re developing much more efficient than our competitors with much less defects. How come?
Lacking formal education in IT I went with common sense instead of standard methods taught at college. This way I avoided some of the common mistakes in the industry.
When doing some research on the differences between our own methods and industry standard, I discovered that what we do much resembles Agile methods. We’re flexible, have hardly any hierarchy and use many iterations. So unknowingly we adopted agile methods and stayed from waterfall as far as possible. I saw waterfall at work, but it made no sense to me. For me it was something for big bad corporations and cubicles, not for lean mean companies whith people who actually enjoy their work.
I chuckle when I hear people talking about agile alomost as if it’s the second coming of JC. For me it’s just commons sense. No more. No less.
Call it what you will, but creating a development environment adaptive to change and expediency will be the only way for organizations to proactively react to their customers evolving needs and survive the downturn.
Thanks for information
Agile – good. Rally UI – not so good.
It will be, IMO, an interesting experiment for Toyota with Agile implementation. Agile is known to work best in small/coherent/face-to-face teams. Actually this is one of its limitations of agile.
Time will tell whether Agile will prove to be a decent and worthwhile alternative for waterfall. This is an ongoing debate between the 2 camps that doesn’t look it’s about to end any soon.
I am glad to inform you of the publication of my new book about Toyota Production System.
The book is titled “The truth about Toyota and TPS” and can be found at the following link: http://amzn.com/2917260025
Regards,
E. Kobayashi.