<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Enterprise Agile Framework Illusion</title>
	<atom:link href="http://www.bigvisible.com/gschlitz/enterprise-agile-framework/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/</link>
	<description></description>
	<lastBuildDate>Tue, 20 Jul 2010 04:54:15 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: George Schlitz</title>
		<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/comment-page-1/#comment-13777</link>
		<dc:creator>George Schlitz</dc:creator>
		<pubDate>Wed, 03 Dec 2008 19:33:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.bigvisible.com/?p=114#comment-13777</guid>
		<description>I think I share all of your experiences.  Darrin - I think your comments are insightful, and I agree.  I think that a part of all this is that somewhere along the way the organization doesn&#039;t want to do the hard work required to change and to be successful, and applies the old mental model to software product development - that you just have to define the process and then you can just follow the steps to successful projects.  If the assumptions behind the leadership and methods in traditional approaches were true, someone -would- be able to define things in such a way, and we wouldn&#039;t need to hire talented people able to think on their own and as part of teams to do the job.  Fortunately these assumptions are not true, and that is why the traditional approaches simply don&#039;t work in practice- despite the lovely diagrams (which are no more than happy-path estimates of how a project might go).  Agile and newer methods wouldn&#039;t exist and be coming out if the traditional thinking was correct.  It is not.

REALLY improving how you do product development - when the approach that isn&#039;t working is based on waterfall and command-and-control type traditional thinking - requires a fundamental change in values.  That&#039;s why I liken it to getting over an addiction - you won&#039;t unless you acknowledge that you have a problem (e.g. that there is a problem in the assumptions behind the more traditional methods), and you won&#039;t successfully change unless this acknowledgement and desire to change exists in leadership and teams.</description>
		<content:encoded><![CDATA[<p>I think I share all of your experiences.  Darrin &#8211; I think your comments are insightful, and I agree.  I think that a part of all this is that somewhere along the way the organization doesn&#8217;t want to do the hard work required to change and to be successful, and applies the old mental model to software product development &#8211; that you just have to define the process and then you can just follow the steps to successful projects.  If the assumptions behind the leadership and methods in traditional approaches were true, someone -would- be able to define things in such a way, and we wouldn&#8217;t need to hire talented people able to think on their own and as part of teams to do the job.  Fortunately these assumptions are not true, and that is why the traditional approaches simply don&#8217;t work in practice- despite the lovely diagrams (which are no more than happy-path estimates of how a project might go).  Agile and newer methods wouldn&#8217;t exist and be coming out if the traditional thinking was correct.  It is not.</p>
<p>REALLY improving how you do product development &#8211; when the approach that isn&#8217;t working is based on waterfall and command-and-control type traditional thinking &#8211; requires a fundamental change in values.  That&#8217;s why I liken it to getting over an addiction &#8211; you won&#8217;t unless you acknowledge that you have a problem (e.g. that there is a problem in the assumptions behind the more traditional methods), and you won&#8217;t successfully change unless this acknowledgement and desire to change exists in leadership and teams.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darrin Ladd</title>
		<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/comment-page-1/#comment-13618</link>
		<dc:creator>Darrin Ladd</dc:creator>
		<pubDate>Mon, 27 Oct 2008 22:53:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.bigvisible.com/?p=114#comment-13618</guid>
		<description>I really like your message and it should resonate well with people. I laughed a little at &quot;The consultancies that come up with them rarely use them...and those few that do have much more highly controlled environments in which to execute than you do&quot; because that is even making the truth nicer than it is. Most consultancies feel pressure to define and present a packaged process solution because &quot;every one else has one.&quot;  The true reality is that 99% of them simply make something up just to have one, none of their people actually understand it or follow it, it is a total bunch of marketing BS. Therefore, when a customer actually buys into it, they are basically putting money towards the hope that the guy that they get on the project can make up a solid process on the fly and make it work. They would be better off hiring monkeys and 
seeing what they come up with, it would be more successful.
 
The sad truth in all of this is that I feel that the greater majority of companies will go the way that you state in your blog....structured process. The main reasons I see are similar to yours but in a little 
different light:
 
1. Lack of a strong leader for each situation in the company: 
Most companies are lucky to have 1 or 2 strong leaders, yet very often Agile requires a strong leader on every project....the Scrum Master. I know that the Scrum Master role can be taught but to truly attain and sustain the dynamic interaction while buffering the teams from distractions and keeping internal calmness within the team takes a very special type of person.
 
2. Laziness: Agile is not easy, it is successful. 
It is much easier for the business people to complain about IT than to define what they really want and successfully lead the development vision by setting the correct priorities. 
It is easier for project managers to check off documentation requirements and MSProject tasks one by one than to truly manage a team, encouraging interaction, buffering distractions, and resolving the issues that come up every day.
It is easier for a mediocre developer to simply produce OK to bad product and work at minimal capacity without any repercussions than to have to report to his/her peers every day on what they have done and what they will accomplish; not only bringing the spotlight on their slow pace but also opening their work to natural peer review.
 
 
I can go on...but at every level the structure process is easier for the non-success driven individual. What many of them don&#039;t realize is that they would be much happier with their career if they changed their process because then they will be producing a good product that matches what the business needs and will be applauded for it. But the laziness 
gets in the way...
 
My 2 cents for the day</description>
		<content:encoded><![CDATA[<p>I really like your message and it should resonate well with people. I laughed a little at &#8220;The consultancies that come up with them rarely use them&#8230;and those few that do have much more highly controlled environments in which to execute than you do&#8221; because that is even making the truth nicer than it is. Most consultancies feel pressure to define and present a packaged process solution because &#8220;every one else has one.&#8221;  The true reality is that 99% of them simply make something up just to have one, none of their people actually understand it or follow it, it is a total bunch of marketing BS. Therefore, when a customer actually buys into it, they are basically putting money towards the hope that the guy that they get on the project can make up a solid process on the fly and make it work. They would be better off hiring monkeys and<br />
seeing what they come up with, it would be more successful.</p>
<p>The sad truth in all of this is that I feel that the greater majority of companies will go the way that you state in your blog&#8230;.structured process. The main reasons I see are similar to yours but in a little<br />
different light:</p>
<p>1. Lack of a strong leader for each situation in the company:<br />
Most companies are lucky to have 1 or 2 strong leaders, yet very often Agile requires a strong leader on every project&#8230;.the Scrum Master. I know that the Scrum Master role can be taught but to truly attain and sustain the dynamic interaction while buffering the teams from distractions and keeping internal calmness within the team takes a very special type of person.</p>
<p>2. Laziness: Agile is not easy, it is successful.<br />
It is much easier for the business people to complain about IT than to define what they really want and successfully lead the development vision by setting the correct priorities.<br />
It is easier for project managers to check off documentation requirements and MSProject tasks one by one than to truly manage a team, encouraging interaction, buffering distractions, and resolving the issues that come up every day.<br />
It is easier for a mediocre developer to simply produce OK to bad product and work at minimal capacity without any repercussions than to have to report to his/her peers every day on what they have done and what they will accomplish; not only bringing the spotlight on their slow pace but also opening their work to natural peer review.</p>
<p>I can go on&#8230;but at every level the structure process is easier for the non-success driven individual. What many of them don&#8217;t realize is that they would be much happier with their career if they changed their process because then they will be producing a good product that matches what the business needs and will be applauded for it. But the laziness<br />
gets in the way&#8230;</p>
<p>My 2 cents for the day</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MikeD</title>
		<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/comment-page-1/#comment-13540</link>
		<dc:creator>MikeD</dc:creator>
		<pubDate>Wed, 08 Oct 2008 23:54:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.bigvisible.com/?p=114#comment-13540</guid>
		<description>that should be mother yeasts!</description>
		<content:encoded><![CDATA[<p>that should be mother yeasts!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MikeD</title>
		<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/comment-page-1/#comment-13539</link>
		<dc:creator>MikeD</dc:creator>
		<pubDate>Wed, 08 Oct 2008 23:53:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.bigvisible.com/?p=114#comment-13539</guid>
		<description>Most Agile implementations I work with are like microbeers that started off with the same mother years and adpated and changed to  take advantage or their locale.  So I&#039;m not sure if the hybrid arguement is the cause or the fact that somebody calling themselves a methodologist is actually a taxidermist - that is someone who takes a living breathing organizism and kills it so they can stuff it and put it in a catalog with other great samples of things that once lived.</description>
		<content:encoded><![CDATA[<p>Most Agile implementations I work with are like microbeers that started off with the same mother years and adpated and changed to  take advantage or their locale.  So I&#8217;m not sure if the hybrid arguement is the cause or the fact that somebody calling themselves a methodologist is actually a taxidermist &#8211; that is someone who takes a living breathing organizism and kills it so they can stuff it and put it in a catalog with other great samples of things that once lived.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marji</title>
		<link>http://www.bigvisible.com/gschlitz/enterprise-agile-framework/comment-page-1/#comment-13538</link>
		<dc:creator>Marji</dc:creator>
		<pubDate>Wed, 08 Oct 2008 21:47:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.bigvisible.com/?p=114#comment-13538</guid>
		<description>George - Love this and enjoy your writing style. How true are your observations!! 

So how and why does this happen???? Over and over and over again and do we think it will ever stop??? 

Here are my initial thoughts and I have no disagreements with anything you put out there. Having been through the exact same situations. As soon as an organization starts going towards hybrid, get your resume out on the street if you are born to make improvements and see them realized because the organization is not going to change and eventually you will lose your mind watching them kill themselves. Particularly if you have observed the same problems happening over and over and over again and no MEASURABLE progress in 6-12 months. 

No one likes change. No one likes to stop smoking, change jobs, etc.fundamentally most people do not like change. Some do but not many.. So the fact that we are saying, change is needed pushes several buttons:

1. The people you are talking to were part of creating what now needs to be fixed
 a. They now have to admit they were part of creating a problem and that there is a problem. 12-step, number 1 - admit that you have a problem. 
 b. IF they admit that they have a problem and YOU actually know how to solve it? WELL now YOU are telling THEM something THEY should have been able to figure out themselves. This is also bad. They wanted to be able to do this. So you have to get them to be able to make the monumental personal discoveries.. It&#039;s not easy.. obviously...BUT it can be done every so gently (sometimes not but timing is everything) but directly. 
But always remember, they don&#039;t really like admitting that they have a problem and that is why, in my opinion that they secretly want to go back to doing things the old way or finidng a way to add something to the new way you are showing them so they are still in the picture. They don&#039;t understand their value yet in the new picture so they are trying to figure a way to fit in.... it&#039;s very sad.. patience is important and excellent coaching from true and experienced coaches. 
2. They must know, as you say, that it will take time. And it&#039;s ok that it does.. One thing at a time. .Love it George, one day at a time. AND they must know and realize how IMPORTANT they are.

3. They MUST be able to see what is in it for THEM professionally. And how they will be rewarded..  particularly if they were rewarded before with heroics. Now how will they be measured? 

        


You must involve and get buy-in from the CEO/CIO or other such people with the authority to trust you and give YOU the authority to go and do what it will take and not block you. Very important. Teach the Business side of the organization, where the requirements and product growth/revenue comes from, get them on board and excited. Get them almost addicted to the concept. Yes you can make changes yes we can adapt to rolling requirements easier however this is what we need from you to do what you need us to do for you. 

Read Weinbergs book on Consulting, the red one. It explains in explicit detail why change is so hard and why we as consultants must deal with this and many tricks and tips on how to.. you&#039;ll all love it. 

Adrenaline junkies/template freaks - a book out there now. Lister/DeMarco and others. Some people have gained success by making heroic acts. We&#039;ll give this project/client to Casey, she&#039;ll do it, she ALWAYS delivers. Little does senior management know how Casey does it. Casey manipulates people so that they are working days, nights, over night, weekends. But she meets the deadlines. Hmmmmm.... Management likes that, everyone is afraid of her because if they disagree, she marks them as bad team players and wants them out... this is a problem and it&#039;s the sign of a very dysfunctional organization that rewards the &quot;Caseys&quot; of the world. Bad bad. 

No one really ever wanted to lose control so they never got past that fear and found their niche in the new world  of agile as a coach. Perhaps they never learned the coaching skills or simply could or would not learn them. Some people will not change. 
They need the pointy haired manager to put together GASP, a .ppt to present to the entire organization of how “Agile” is going to save the world just like it helped one team.  However this person having failed to understood the basic concepts failed also to understand that each team consists of different people/personalities/communication styles/etc  and hence, you can’t cookie cutter any methodology, least of which agile which is based very much on customizing it to the culture and the people in each team. While you can make some of the guidelines more rules vs. what “Jack Sparrow” said in Pirates, the code is more of a “guideline”, you must be able to customize the implementation somewhat but not so much that it no longer resembles anything.

Few people understand that Agile methodologies are highly disciplined and tolerate no less... yet so many people believe that teams don&#039;t need coaches that people will just figure it out and if they can&#039;t oh well. Requirements will change, won&#039;t be documented and people will jump in and do other peoples jobs and &quot;whatever it takes&quot; and that is all being &quot;agile&quot;. They just don&#039;t get it. Worse, they&#039;ve read a book and are prescriptive. I&#039;m not sure which is worse... sigh...

We need more good coaches out there... and 12-step meetings for those who finally admit, they have a problem.

-M</description>
		<content:encoded><![CDATA[<p>George &#8211; Love this and enjoy your writing style. How true are your observations!! </p>
<p>So how and why does this happen???? Over and over and over again and do we think it will ever stop??? </p>
<p>Here are my initial thoughts and I have no disagreements with anything you put out there. Having been through the exact same situations. As soon as an organization starts going towards hybrid, get your resume out on the street if you are born to make improvements and see them realized because the organization is not going to change and eventually you will lose your mind watching them kill themselves. Particularly if you have observed the same problems happening over and over and over again and no MEASURABLE progress in 6-12 months. </p>
<p>No one likes change. No one likes to stop smoking, change jobs, etc.fundamentally most people do not like change. Some do but not many.. So the fact that we are saying, change is needed pushes several buttons:</p>
<p>1. The people you are talking to were part of creating what now needs to be fixed<br />
 a. They now have to admit they were part of creating a problem and that there is a problem. 12-step, number 1 &#8211; admit that you have a problem.<br />
 b. IF they admit that they have a problem and YOU actually know how to solve it? WELL now YOU are telling THEM something THEY should have been able to figure out themselves. This is also bad. They wanted to be able to do this. So you have to get them to be able to make the monumental personal discoveries.. It&#8217;s not easy.. obviously&#8230;BUT it can be done every so gently (sometimes not but timing is everything) but directly.<br />
But always remember, they don&#8217;t really like admitting that they have a problem and that is why, in my opinion that they secretly want to go back to doing things the old way or finidng a way to add something to the new way you are showing them so they are still in the picture. They don&#8217;t understand their value yet in the new picture so they are trying to figure a way to fit in&#8230;. it&#8217;s very sad.. patience is important and excellent coaching from true and experienced coaches.<br />
2. They must know, as you say, that it will take time. And it&#8217;s ok that it does.. One thing at a time. .Love it George, one day at a time. AND they must know and realize how IMPORTANT they are.</p>
<p>3. They MUST be able to see what is in it for THEM professionally. And how they will be rewarded..  particularly if they were rewarded before with heroics. Now how will they be measured? </p>
<p>You must involve and get buy-in from the CEO/CIO or other such people with the authority to trust you and give YOU the authority to go and do what it will take and not block you. Very important. Teach the Business side of the organization, where the requirements and product growth/revenue comes from, get them on board and excited. Get them almost addicted to the concept. Yes you can make changes yes we can adapt to rolling requirements easier however this is what we need from you to do what you need us to do for you. </p>
<p>Read Weinbergs book on Consulting, the red one. It explains in explicit detail why change is so hard and why we as consultants must deal with this and many tricks and tips on how to.. you&#8217;ll all love it. </p>
<p>Adrenaline junkies/template freaks &#8211; a book out there now. Lister/DeMarco and others. Some people have gained success by making heroic acts. We&#8217;ll give this project/client to Casey, she&#8217;ll do it, she ALWAYS delivers. Little does senior management know how Casey does it. Casey manipulates people so that they are working days, nights, over night, weekends. But she meets the deadlines. Hmmmmm&#8230;. Management likes that, everyone is afraid of her because if they disagree, she marks them as bad team players and wants them out&#8230; this is a problem and it&#8217;s the sign of a very dysfunctional organization that rewards the &#8220;Caseys&#8221; of the world. Bad bad. </p>
<p>No one really ever wanted to lose control so they never got past that fear and found their niche in the new world  of agile as a coach. Perhaps they never learned the coaching skills or simply could or would not learn them. Some people will not change.<br />
They need the pointy haired manager to put together GASP, a .ppt to present to the entire organization of how “Agile” is going to save the world just like it helped one team.  However this person having failed to understood the basic concepts failed also to understand that each team consists of different people/personalities/communication styles/etc  and hence, you can’t cookie cutter any methodology, least of which agile which is based very much on customizing it to the culture and the people in each team. While you can make some of the guidelines more rules vs. what “Jack Sparrow” said in Pirates, the code is more of a “guideline”, you must be able to customize the implementation somewhat but not so much that it no longer resembles anything.</p>
<p>Few people understand that Agile methodologies are highly disciplined and tolerate no less&#8230; yet so many people believe that teams don&#8217;t need coaches that people will just figure it out and if they can&#8217;t oh well. Requirements will change, won&#8217;t be documented and people will jump in and do other peoples jobs and &#8220;whatever it takes&#8221; and that is all being &#8220;agile&#8221;. They just don&#8217;t get it. Worse, they&#8217;ve read a book and are prescriptive. I&#8217;m not sure which is worse&#8230; sigh&#8230;</p>
<p>We need more good coaches out there&#8230; and 12-step meetings for those who finally admit, they have a problem.</p>
<p>-M</p>
]]></content:encoded>
	</item>
</channel>
</rss>
