Comments for bigvisible.com http://www.bigvisible.com Fri, 21 Nov 2008 14:26:18 +0000 http://wordpress.org/?v=2.6.2 Comment on The Serenity Prayer as an Agile Mindset by bbozzuto http://www.bigvisible.com/bbozzuto/the-serenity-prayer-as-an-agile-mindset/#comment-13647 bbozzuto Tue, 04 Nov 2008 19:19:27 +0000 http://www.bigvisible.com/?p=156#comment-13647 Jay, I like your analogy between a factory verse a research laboratory. It certainly cuts to the heart of the challenges of efficiency verse effectiveness. However, that analogy is perhaps itself a little limited, because there are things we do that should be like a factory. A team should have sufficient discipline to model consistently, code to standards, and use CI to run frequent builds. I think this is one big challenge I've found, as some people have a hard time distinguishing where they should be flexible and where they should have discipline. Jay, I like your analogy between a factory verse a research laboratory. It certainly cuts to the heart of the challenges of efficiency verse effectiveness. However, that analogy is perhaps itself a little limited, because there are things we do that should be like a factory. A team should have sufficient discipline to model consistently, code to standards, and use CI to run frequent builds. I think this is one big challenge I’ve found, as some people have a hard time distinguishing where they should be flexible and where they should have discipline.

]]> Comment on The Serenity Prayer as an Agile Mindset by Jay Conne http://www.bigvisible.com/bbozzuto/the-serenity-prayer-as-an-agile-mindset/#comment-13639 Jay Conne Mon, 03 Nov 2008 18:23:06 +0000 http://www.bigvisible.com/?p=156#comment-13639 Brian - nicely put. As I wrote in a comment on a post by Mike Dwyer, I find the metaphor of R&D vs manufacturing resonates well with my clients. In R&D, you are in discovery mode where it's always safe to say, "I don't know." and "I tried this, it didn't work, and here's what I learned." Philosophically speaking, in a very practical way... If we accept that there's effectively infinite to know and we learn parts by trying things, we need to discover enough to achieve the goal of the moment. That as good as it gets and is sufficient. Thanks for your post. Jay Brian - nicely put. As I wrote in a comment on a post by Mike Dwyer, I find the metaphor of R&D vs manufacturing resonates well with my clients. In R&D, you are in discovery mode where it’s always safe to say, “I don’t know.” and “I tried this, it didn’t work, and here’s what I learned.”

Philosophically speaking, in a very practical way…
If we accept that there’s effectively infinite to know and we learn parts by trying things, we need to discover enough to achieve the goal of the moment. That as good as it gets and is sufficient. Thanks for your post.

Jay

]]> Comment on Agile Leadership by Jay Conne http://www.bigvisible.com/mdwyer/agile-leadership/#comment-13637 Jay Conne Mon, 03 Nov 2008 18:10:48 +0000 http://www.bigvisible.com/?p=66#comment-13637 Mike - I like your summary perspective and agree completely. I like to view it in ethical terms as honesty about what we know and have yet to learn; honesty about what's inside and outside the speaker. In the case of SW development, it's specifically about not confusing specification with speculation, and then getting busy with cycles of learning and creating value. I find another distinction resonates well - the R&D vs manufacturing context. Most people find the R&D model compelling to explain our approach. Thanks, Jay Mike - I like your summary perspective and agree completely. I like to view it in ethical terms as honesty about what we know and have yet to learn; honesty about what’s inside and outside the speaker. In the case of SW development, it’s specifically about not confusing specification with speculation, and then getting busy with cycles of learning and creating value. I find another distinction resonates well - the R&D vs manufacturing context. Most people find the R&D model compelling to explain our approach.

Thanks, Jay

]]> Comment on The Enterprise Agile Framework Illusion by Darrin Ladd http://www.bigvisible.com/gschlitz/enterprise-agile-framework/#comment-13618 Darrin Ladd Mon, 27 Oct 2008 22:53:55 +0000 http://www.bigvisible.com/?p=114#comment-13618 I really like your message and it should resonate well with people. I laughed a little at "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" because that is even making the truth nicer than it is. Most consultancies feel pressure to define and present a packaged process solution because "every one else has one." 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'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 I really like your message and it should resonate well with people. I laughed a little at “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” because that is even making the truth nicer than it is. Most consultancies feel pressure to define and present a packaged process solution because “every one else has one.” 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’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

]]> Comment on Organizational Debt by Bob Galen http://www.bigvisible.com/bbozzuto/organizational-debt/#comment-13563 Bob Galen Mon, 13 Oct 2008 16:16:35 +0000 http://www.bigvisible.com/?p=97#comment-13563 I would also add to organizational debt things more so at a cross-functional team level, for example: - level of open mindedness to changing & improving practices - level of cross team collaboration (ex: developers & testers, requirements folks and developers, etc.) - level of 'professionalism' exhibited within each of the functional teams (ex: developers writing good unit tests or participating in code reviews) - cultural norms around fostering respectful 'listening', conducting high-impact discussions - dynamics around Meetings ;-) Just give a flavor to extensions to the notion of organizational debt. Did I say I really liked this idea? I DO! Might be worth defining some patterns that you've seen thru your travels... I would also add to organizational debt things more so at a cross-functional team level, for example:

- level of open mindedness to changing & improving practices
- level of cross team collaboration (ex: developers & testers, requirements folks and developers, etc.)
- level of ‘professionalism’ exhibited within each of the functional teams (ex: developers writing good unit tests or participating in code reviews)
- cultural norms around fostering respectful ‘listening’, conducting high-impact discussions
- dynamics around Meetings ;-)

Just give a flavor to extensions to the notion of organizational debt.

Did I say I really liked this idea? I DO! Might be worth defining some patterns that you’ve seen thru your travels…

]]> Comment on Determining Actors and Defining Back-end Stories by Bob Galen http://www.bigvisible.com/asingh/determining-actors-and-defining-back-end-stories/#comment-13562 Bob Galen Mon, 13 Oct 2008 10:23:09 +0000 http://www.bigvisible.com/?p=64#comment-13562 Alex - just wanted to say thank you for this nice diversion on stories with some useful examples. I don't find enough "real examples" of using User Stories in the community and I appreciate your efforts! It would be nice to see a detailed follow-up on acceptance test(s) definition in this same context ;-) Alex - just wanted to say thank you for this nice diversion on stories with some useful examples. I don’t find enough “real examples” of using User Stories in the community and I appreciate your efforts!

It would be nice to see a detailed follow-up on acceptance test(s) definition in this same context ;-)

]]> Comment on The problem with SD Methodology is…that there is too much method by The Enterprise Agile Framework Illusion | bigvisible.com http://www.bigvisible.com/gschlitz/too-much-method/#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 [...]

]]> Comment on The Enterprise Agile Framework Illusion by MikeD http://www.bigvisible.com/gschlitz/enterprise-agile-framework/#comment-13540 MikeD Wed, 08 Oct 2008 23:54:00 +0000 http://www.bigvisible.com/?p=114#comment-13540 that should be mother yeasts! that should be mother yeasts!

]]> Comment on The Enterprise Agile Framework Illusion by MikeD http://www.bigvisible.com/gschlitz/enterprise-agile-framework/#comment-13539 MikeD Wed, 08 Oct 2008 23:53:21 +0000 http://www.bigvisible.com/?p=114#comment-13539 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'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. 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’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.

]]> Comment on The Enterprise Agile Framework Illusion by Marji http://www.bigvisible.com/gschlitz/enterprise-agile-framework/#comment-13538 Marji Wed, 08 Oct 2008 21:47:50 +0000 http://www.bigvisible.com/?p=114#comment-13538 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'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'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't understand their value yet in the new picture so they are trying to figure a way to fit in.... it'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'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'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'll give this project/client to Casey, she'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's the sign of a very dysfunctional organization that rewards the "Caseys" 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't need coaches that people will just figure it out and if they can't oh well. Requirements will change, won't be documented and people will jump in and do other peoples jobs and "whatever it takes" and that is all being "agile". They just don't get it. Worse, they've read a book and are prescriptive. I'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 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’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’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’t understand their value yet in the new picture so they are trying to figure a way to fit in…. it’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’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’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’ll give this project/client to Casey, she’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’s the sign of a very dysfunctional organization that rewards the “Caseys” 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’t need coaches that people will just figure it out and if they can’t oh well. Requirements will change, won’t be documented and people will jump in and do other peoples jobs and “whatever it takes” and that is all being “agile”. They just don’t get it. Worse, they’ve read a book and are prescriptive. I’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

]]>