Agile and ITIL - what is it (in laymans terms!)

  • Thread starter Thread starter ~J~
  • Start date Start date
Costs will be reduced but the main aim of a Lean driven environment is delivering exactly what is wanted as early as possible.

I've never heard of agile and Toyota together. Only Lean and Toyota.
 
Jetstar - I don't know if there's confusion here, but Agile is a methodology, well, more than that, but it's applied specifically to software. I can't understand how Toyota are using agile, unless they are developing software.
 
Agile is not specifically software development. This is also a misconception of Agile. It is a management system/methodology/whatever. Just because you are not typing code, does not mean you cannot use Agile.

Just googling for "Toyota and Agile" gives pages of results.
 
Agile is not specifically software development. This is also a misconception of Agile. It is a management system/methodology/whatever. Just because you are not typing code, does not mean you cannot use Agile.

Just googling for "Toyota and Agile" gives pages of results.

Agile IS about software development though. Yes, you can apply the methods to other areas, but what you are applying is not agile, it's lean thinking which came from Toyota. Toyota might have learnt from people who have worked with agile, but to say they use it is misleading, since agile was born from their ideas, not vice versa!

From the Agile wiki page:
The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development.
 
Agile Management.. yes, it's taken from Agile Software development, but as long as you have a product, a list of changes/issues/things to do, you can perform Agile. I really don't see why you are so eager to keep Agile pinned on software development when it really isn't, other than it was coined "Agile Software Development" after a number of high profile developers decided to use The Toyota Way.
 
I've had a (very) quick look and the only places I can see Toyota and agile together are comparisons and descriptions. Not that either was particularly derived from the other or used by Toyota.

Lean and Agile are different things.
 
I've had a (very) quick look and the only places I can see Toyota and agile together are comparisons and descriptions. Not that either was particularly derived from the other or used by Toyota.

Lean and Agile are different things.

Well we can rule out Toyota deriving their ideas from Agile given the time difference, but it's fair to say Agile used Toyotas principles.

Jetstar - are we talking about a different Agile here? Because the one i know started as a software development methodology founded on lean principles. Now, if you start applying those principles to other areas, you aren't really using agile, you are using the principles that agile was built upon. From what I can see, you are calling Toyota's production principles in the 70s/80s agile, which they are not.
 
Toyota designed Lean years ago and it was used by many others including NEC and DELL.

Agile, Lean, Six sigma, TQM, Catalyst, COA, SOA, Prince2, TOGAF, Zachmans etc etc are all differing methodologies and frameworks. All have their strengths and weaknesses. Your best bet is to pick and choose the parts that work well for the staff you have and the company culture.

Companies / consultants will always sell you the Purist view of their preferred application / methodology / framework - they have to. However in reality the purists view never really works. Taking parts from each however will enable you to deliver.

The main thing that all these point to however is using your common sense. Companies do stupid things because people are either not empowered or feel too scared to stand up and go thats stupid.

George Washington and Machiavelli both have good quotes on this.

Machiavelli The Prince said:
"And one should bear in mind that there is nothing more difficult to execute, nor more dubious of success, nor more dangerous to administer than to introduce a new order to things; for he who introduces it has all those who profit from the old order as his enemies; and he has only lukewarm allies in all those who might profit from the new. This lukewarmness partly stems from fear of their adversaries, who have the law on their side, and partly from the skepticism of men, who do not truly believe in new things unless they have personal experience in them."

and

washington said:
One of the difficulties in bringing about change in your organisation is that you must do so through the persons who have been most successful in that organisation no matter how faulty the system or organisation. To such a person, you see, it is the best of all possible organisations, because look who was selected by it and look who succeeded most within it. Yet these are the very people through whom we much bring about improvements.

Agile in itself to me changes IT from only seeing the corridor, to being able to see the different doors and rooms along the route and finding better routes and instead of ignoring them and just heading to the end of the corridor they can adapt to a better solution.

The absolute key to agile is communication and product owners.

A good book to read on change is Hammer and Champney Reengineering the Corporation.
 
Lean and Agile are different things.
One is derived from the other. Not different entirely.
Well we can rule out Toyota deriving their ideas from Agile given the time difference, but it's fair to say Agile used Toyotas principles.

Jetstar - are we talking about a different Agile here? Because the one i know started as a software development methodology founded on lean principles. Now, if you start applying those principles to other areas, you aren't really using agile, you are using the principles that agile was built upon. From what I can see, you are calling Toyota's production principles in the 70s/80s agile, which they are not.
Agile is about adapting and evolving.. this applies to Agile it self. Toyota are using Agile. They may not announce they are using it. They may not be writing papers/articles that say they are using it. They may not even call it Agile, but what they do very much is Agile. It may be a different title, but it is Agile.
 
Toyota designed Lean years ago and it was used by many others including NEC and DELL.

Agile, Lean, Six sigma, TQM, Catalyst, COA, SOA, Prince2, TOGAF, Zachmans etc etc are all differing methodologies and frameworks. All have their strengths and weaknesses. Your best bet is to pick and choose the parts that work well for the staff you have and the company culture.

Companies / consultants will always sell you the Purist view of their preferred application / methodology / framework - they have to. However in reality the purists view never really works. Taking parts from each however will enable you to deliver.

The main thing that all these point to however is using your common sense. Companies do stupid things because people are either not empowered or feel too scared to stand up and go thats stupid.

George Washington and Machiavelli both have good quotes on this.



and



Agile in itself to me changes IT from only seeing the corridor, to being able to see the different doors and rooms along the route and finding better routes and instead of ignoring them and just heading to the end of the corridor they can adapt to a better solution.

The absolute key to agile is communication and product owners.

A good book to read on change is Hammer and Champney Reengineering the Corporation.

Excellent post Bar :) Quite agree on the importance of the product owner - we went from one extreme of having a guy who spent all his time working alongside us, joining in the team banter and so on to someone who we didn't see for weeks! The difference in output from the two projects was quite obvious!
 
Excellent post Bar :) Quite agree on the importance of the product owner - we went from one extreme of having a guy who spent all his time working alongside us, joining in the team banter and so on to someone who we didn't see for weeks! The difference in output from the two projects was quite obvious!

Thanks, Im acting as Product Owner on one of my projects at the moment and the IT solution is being developed by a Norwegian software house, as a result I have a Product Owner Proxy there and we co-ordinate all.

Dj_Jestar - you could replace the word "agile" with "common-sense" and it would also be true. Why the insistance that they are using "agile"?
 
And for the record, it's not a "support" role. Even the recruitment guy asked if I'd heard of it, because he hasn't.

If he is a specialised IT recruitment guy, then find another agency as I would expect anyone working in recruitment for IT to know what ITIL is.
 
If he is a specialised IT recruitment guy, then find another agency as I would expect anyone working in recruitment for IT to know what ITIL is.

He isn't.

It was a job I saw on a well known website, I applied, he rang up me. That's it I'm afraid.

Although do have an interview next week, so, my lack of knowledge on 4 letters isn't that bad.
 
Thanks, Im acting as Product Owner on one of my projects at the moment and the IT solution is being developed by a Norwegian software house, as a result I have a Product Owner Proxy there and we co-ordinate all.

Dj_Jestar - you could replace the word "agile" with "common-sense" and it would also be true. Why the insistance that they are using "agile"?
because this thread is (at least half) about Agile. It is also the best descriptive title.. Agility = Agile.
 
ITIL + CMDB = many years of pain for me when I was in IT support.
Did the exams, did change management and sat on the phones.....rotted my brain from the inside and lost the will to live every other hour :D
 
Back
Top Bottom