Comments on: The problem with SD Methodology is…that there is too much method http://www.bigvisible.com/gschlitz/too-much-method/ Tue, 20 Jul 2010 04:54:15 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: The Enterprise Agile Framework Illusion | bigvisible.com http://www.bigvisible.com/gschlitz/too-much-method/comment-page-1/#comment-13554 The Enterprise Agile Framework Illusion | bigvisible.com Sun, 12 Oct 2008 15:33:51 +0000 http://www.bigvisible.com/?p=80#comment-13554 [...] the farther you get from the real factors that influence project success (there is “Too Much Stuff“) •    They are an easy way out of having to overcome your dysfunctions •    You [...] [...] the farther you get from the real factors that influence project success (there is “Too Much Stuff“) •    They are an easy way out of having to overcome your dysfunctions •    You [...]

]]> By: George Schlitz http://www.bigvisible.com/gschlitz/too-much-method/comment-page-1/#comment-8393 George Schlitz Fri, 25 Jul 2008 03:39:36 +0000 http://www.bigvisible.com/?p=80#comment-8393 Thanks for your comments! I am not sure I understand the first, and would like to hear more. I agree and have had similar experiences to Amy's... Thanks for your comments! I am not sure I understand the first, and would like to hear more.

I agree and have had similar experiences to Amy’s…

]]> By: Amy http://www.bigvisible.com/gschlitz/too-much-method/comment-page-1/#comment-6465 Amy Wed, 09 Jul 2008 22:50:53 +0000 http://www.bigvisible.com/?p=80#comment-6465 This is very true!!!! Two pieces really jumped out at me...The "too much stuff" theory and "Consumables v. Deliverables"...I have found time and time again that "a few words spoken is worth a thousand PRDs". I.E. There is too much paperwork and not enough face to face contact in most of these approaches which has huge implications. A lot gets lost in translation or worse yet never gets translated at all...In fact this can go on for months or even years!!! This can continue past the release date until the "bug" discovery phase aka new features (aka, the original features that never got fleshed out because people were writing past one another). As psychologically hard to swallow as it may be for many experienced process lovers, a combination of conversations one on one and in groups (depending on the needs at a given point in time) can accomplish far more in a short time than a long document or set of email chains. I am learning that most people are too ADD or think they are too busy or really, more often so, just simply don't want to read these things (myself included). I think this is human nature not a failure of process or laziness. However, if you start chatting with them, they will talk for just as long as it would have taken to read a PRD and give you all the information you need. Why? Maybe because talking is more fun. People like to hear themselves talk. It is less exhausting...There are probably a thousand reasons. All I know is that it seems to be true time and time again. Also, docs and emails are by definition one sided. One person works on it at a time as opposed to a conversation which is by nature, interactive. Even if you do "paired documentation" which I just made up because I have never seen it done, only one person can really write at a time or if you try to do it together, people get bored, doze off, their eyes get tired staring at the overhead. Usually, someone takes the lead and owns it...It just doesn't lend itself well to being a group activity or a join effort in the same way that a conversation does and in most cultures it is completely fragmented. If one person isnt owning it, people pass it around and own it for a time period. Also, the efficiency lost during task switching as people keep re-reading a document and grasp and make changes doesn't come into play when communicating verbally. In addition, the heavy documentation culture has psychological impacts as well. For example, there is often a sterility in the relationships that evolves culturally which is unconscious as well. Again, human nature, not anyone's fault. When people are isolated from each other regularly staring at their screens and prepping for sign-offs, the collaborative mood just doesn't come to life. As you alluded to, this culture promotes the mine and yours mentality. Another thing you mentioned was "consumables versus deliverables". I think I am seeing why this is hard for many cultures to adapt. Again,t human nature at work. Like you said, too much stuff...I have seen it over and over again with all company sizes and between a variety of personality types. When people invest a lot of work and time into long detailed documents, they naturally develop a sense of pride in their work and an unconscious need to legitimate the value of what was produced even if what they are trying to say could be communicated more easily and effectively via a few words and some face to face contact. Naturally, this investment creates a ball and chain effect because a person or team becomes attached to the documentation and teams stop asking why are we using this and is this working? Even if only the author has bought into it, others will pretend to play along but unconsciously ignore it to some extent. Or the team buys in but no one is really on the same page about what it all means. And psychologically, the further down that road a person or a team or a company gets, the harder it is to admit that there is an easier way. It's funny actually. I just had an experience like this at my new job where I started this week. Someone wrote a doc on their own for a big upcoming project based on their limited knowledge. They still need a bunch of info that is locked in other peoples heads...They have tried for weeks to get everyone to read it but people sort of blew it off. And the project hasn't started yet. I threw together an informal kickoff meeting, humored the author by attaching the document to the invite, but asked everyone to think about what they want to accomplish in three feature areas. Then I ran around talking to all the attendees about the upcoming meeting asking them questions under the guise of being new but mostly my motive was to get them to think about what they should be preparing to ask and contribute in the meeting. I communicated various things between people and asked everyone to individually come up with a short list of things they want to make sure to cover just for their own notes to bring with them and restated the goal of the meeting as a kickoff to come up with an initial set of features. I told the doc author I promised to get whatever comes out of the meeting into his document once we have a better understanding. Hopefully they have done their mental prep work just by talking about it all out loud. When we get together as a team, they can talk to each other efficiently to understand the requirements collaboratively since really no one has bought into that goal before now when the doc was circulating via email. I noticed that it was easy to talk to people and share information across group members in a short time running around. I also noticed that people started to own a share of the preparation simply by being asked questions and being told what the goal of the meeting was in a vague and open-ended way, without reference to specific documents. I am looking forward to seeing how that progresses. I guess the point of all that was to say I agree with you!!! And...Selfishly to hone in on one of my very specific pet peeves in the "too much stuff" category which is death by the written word! I hope your site will let me post this verbose reply!!! Perhaps it is "too much stuff" :) This is very true!!!! Two pieces really jumped out at me…The “too much stuff” theory and “Consumables v. Deliverables”…I have found time and time again that “a few words spoken is worth a thousand PRDs”. I.E. There is too much paperwork and not enough face to face contact in most of these approaches which has huge implications. A lot gets lost in translation or worse yet never gets translated at all…In fact this can go on for months or even years!!! This can continue past the release date until the “bug” discovery phase aka new features (aka, the original features that never got fleshed out because people were writing past one another). As psychologically hard to swallow as it may be for many experienced process lovers, a combination of conversations one on one and in groups (depending on the needs at a given point in time) can accomplish far more in a short time than a long document or set of email chains. I am learning that most people are too ADD or think they are too busy or really, more often so, just simply don’t want to read these things (myself included). I think this is human nature not a failure of process or laziness. However, if you start chatting with them, they will talk for just as long as it would have taken to read a PRD and give you all the information you need. Why? Maybe because talking is more fun. People like to hear themselves talk. It is less exhausting…There are probably a thousand reasons. All I know is that it seems to be true time and time again. Also, docs and emails are by definition one sided. One person works on it at a time as opposed to a conversation which is by nature, interactive. Even if you do “paired documentation” which I just made up because I have never seen it done, only one person can really write at a time or if you try to do it together, people get bored, doze off, their eyes get tired staring at the overhead. Usually, someone takes the lead and owns it…It just doesn’t lend itself well to being a group activity or a join effort in the same way that a conversation does and in most cultures it is completely fragmented. If one person isnt owning it, people pass it around and own it for a time period. Also, the efficiency lost during task switching as people keep re-reading a document and grasp and make changes doesn’t come into play when communicating verbally. In addition, the heavy documentation culture has psychological impacts as well. For example, there is often a sterility in the relationships that evolves culturally which is unconscious as well. Again, human nature, not anyone’s fault. When people are isolated from each other regularly staring at their screens and prepping for sign-offs, the collaborative mood just doesn’t come to life. As you alluded to, this culture promotes the mine and yours mentality. Another thing you mentioned was “consumables versus deliverables”. I think I am seeing why this is hard for many cultures to adapt. Again,t human nature at work. Like you said, too much stuff…I have seen it over and over again with all company sizes and between a variety of personality types. When people invest a lot of work and time into long detailed documents, they naturally develop a sense of pride in their work and an unconscious need to legitimate the value of what was produced even if what they are trying to say could be communicated more easily and effectively via a few words and some face to face contact. Naturally, this investment creates a ball and chain effect because a person or team becomes attached to the documentation and teams stop asking why are we using this and is this working? Even if only the author has bought into it, others will pretend to play along but unconsciously ignore it to some extent. Or the team buys in but no one is really on the same page about what it all means. And psychologically, the further down that road a person or a team or a company gets, the harder it is to admit that there is an easier way. It’s funny actually. I just had an experience like this at my new job where I started this week. Someone wrote a doc on their own for a big upcoming project based on their limited knowledge. They still need a bunch of info that is locked in other peoples heads…They have tried for weeks to get everyone to read it but people sort of blew it off. And the project hasn’t started yet. I threw together an informal kickoff meeting, humored the author by attaching the document to the invite, but asked everyone to think about what they want to accomplish in three feature areas. Then I ran around talking to all the attendees about the upcoming meeting asking them questions under the guise of being new but mostly my motive was to get them to think about what they should be preparing to ask and contribute in the meeting. I communicated various things between people and asked everyone to individually come up with a short list of things they want to make sure to cover just for their own notes to bring with them and restated the goal of the meeting as a kickoff to come up with an initial set of features. I told the doc author I promised to get whatever comes out of the meeting into his document once we have a better understanding. Hopefully they have done their mental prep work just by talking about it all out loud. When we get together as a team, they can talk to each other efficiently to understand the requirements collaboratively since really no one has bought into that goal before now when the doc was circulating via email. I noticed that it was easy to talk to people and share information across group members in a short time running around. I also noticed that people started to own a share of the preparation simply by being asked questions and being told what the goal of the meeting was in a vague and open-ended way, without reference to specific documents. I am looking forward to seeing how that progresses.
I guess the point of all that was to say I agree with you!!! And…Selfishly to hone in on one of my very specific pet peeves in the “too much stuff” category which is death by the written word! I hope your site will let me post this verbose reply!!! Perhaps it is “too much stuff” :)

]]> By: Amanda Abelove http://www.bigvisible.com/gschlitz/too-much-method/comment-page-1/#comment-2645 Amanda Abelove Fri, 30 May 2008 05:47:19 +0000 http://www.bigvisible.com/?p=80#comment-2645 Interesting. I disagree. I think that there is lack of ownership because nobody bothers defining the critical need and primary differentiator in 200 words or less. Interesting. I disagree. I think that there is lack of ownership because nobody bothers defining the critical need and primary differentiator in 200 words or less.

]]>