Company A Purchases Company B
So this all starts innocently enough, one company seeing an opportunity to fill a gap in its own game plan purchases another perfectly running company, on the surface. The company doing the purchasing does their due diligence, reviews the books and game plan of the company they are planning on buying to make sure that everything seems like it is on the up and up. This whole process goes smoothly and everything seems to check out. The idea over all is awesome because it fills a hole that company A has in its offerings or business plans. The purchase moves forward.
The Excitement reaches a peek
Both companies are very happy that things are moving forward. The documents are being put together and everyone is having their lawyers look over and red line them. This is a time of satisfaction for both companies involved - a time of celebration. The final signed items are in and the purchase is complete. They are now a single company, this is when the measurements begin.
Making their mark
Company B (The purchased company) now starts to feel that they have to make an impression, show their metal and let everyone know that they have been very successful and that Company A purchased them for a reason. They try consistently to show how what they do in terms of development and process is the best thing since sliced bread. Company B goes out of their way to make sure that everyone knows that the way the do things has worked for them and they want Company A to know what their past experience and success is. This process does quite the opposite however and starts to make Company A staff think that Company B staff are pompous and think that they are better then everyone else. Both sides start to feel slighted and no one feels as if things are working smoothly.
My way or the high way
I once wrote about this very topic when I was talking about management but here, in this situation, it becomes a mechanism for how communications between both companies go. Company A thinks that they are right, Company B thinks that they are right and in the end - nothing productive gets done. If something productive gets done it is generally due to people pushing through their own personal preferences and differences and not because any of the communications or relations between the two companies have gotten any better. This posturing may eventually break down and one or more managers on either side step in and just lay down the law. This sometimes has a good effect and other times has the opposite feel. Without a solid direction of 'ownership' and decisions making however - this state of afairs gets set up to continue to repeat itself over and over and over with each project that is attempted that is inclusive of both sides.
Mine is bigger then yours
In the end the whole thing becomes some sort of bizarre mating ritual where both sides are whipping IT out and stating that theirs is the biggest in the room. In the end it breaks down into a childish US vs. THEM when it didn't need to.
What is gained? Nothing really... reality is that no one is going to get canned, ideas come and go but good people, when respected, stay. This makes for some of the best situations where really good things can happen if we just stand back and let them. Instead one or the other side feels as though they are being ignored or something else and bad blood builds and builds leading no where good. We spend more time measuring one another rather then just doing good work that we both know that we are capable of doing. Its a bit cliche but:
Can't we all just get along?
We need to stop measuring each others male genitalia and get down to doing the work that we both know we can, transparently, cohesively and without fear. Sharing all blemishes, pimples and high points in an attempt to pick the best of both sides and get the BEST possible answer for all rather then a semi good answer for one or the other.
Thursday, March 26, 2009
Monday, March 23, 2009
Superfluous Features
from: http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=967
"Before going on I should like to explain why I may have objections to "superfluous features". Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra". In that stage of the discussion I shall stress that the design would have been better without the feature under discussion. If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better off without it. If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely."
I wrote a post a while back on some things being overly complicated in which I was talking about some new features being introduced into the java language. I think the above quote rather proves my point. If by adding a new feature you are claiming that only a select few people would be capable of using it and those who don't know how or wouldn't use it - Shouldn't, then you are adding something that should be considered superfluous. If the feature is impossible to use well or as intended - Why have it at all?
"Before going on I should like to explain why I may have objections to "superfluous features". Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra". In that stage of the discussion I shall stress that the design would have been better without the feature under discussion. If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better off without it. If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely."
I wrote a post a while back on some things being overly complicated in which I was talking about some new features being introduced into the java language. I think the above quote rather proves my point. If by adding a new feature you are claiming that only a select few people would be capable of using it and those who don't know how or wouldn't use it - Shouldn't, then you are adding something that should be considered superfluous. If the feature is impossible to use well or as intended - Why have it at all?
Agile, Agilsts and philsophy
Being Agile
So I recently read an interesting article on the decline and fall of the agilists. I have to admit that it was an interesting read and it was not what I was expecting at all. I had decided on clicking the link that I was heading to read an article that was lambasting agile as a whole, and in specific the people who supposedly support and enable people to be agile in their enterprise. What I got was different. What I got was a point of view on people being far to rigid in their ideology, the agilists, the evangelists (supposedly) of the agile software development 'movement'. The point of view was decisive and accurate in my opinion, but not because agile is anything specifically different or the people who support it are any different - but because what I get out of it is an equation of an agilist to a terrorist or other extreamist.
Becoming an avid agile supporter
Over the years I have become a rather avid supporter of the agile methodologies. Scrum, XP and a few others have become the ways and methods that I would naturally choose to use when I attempt to do software development. These mthods are also the way in which I would hope that the business that I work for would choose to do their software development work. This of course is not always the case. Like most people I have worked for companies that have waterfall methodologies or other ways to do software development. These methods in some ways work for the companies that have adopted them. Sometimes they work very very well for those companies. They get alot done with their waterfall systems and feel that they have accomplished alot. It is my beliefe that even those companies could get more out of using agile methods. This makes me a supporter of agile, but it doesn't yet make me an agilist. It means that I would choose to attempt to talk the people I work with into giving agile methods a try - But I am not going to dictate that they need to do XP to be agile. More it is to describe that I am going to attempt to let people know what I have seen work in other places using my experience to try and allow a change to occur in the company. One that hopfully will get them to recognize a benefit.
The agilist in hiding
Does the desire to only use Agile methods make me an agilst. Possibly, but what I think differentiates me from the agilsts that are pointed out in the article is that I don't support doing agile in one set and unchanging way. One of the tenants of the agile movement is that the process has to be about the 'people' involved - the individuals and interactions before the processes and tools. You always have to start with the people. You have to look at what the people do, see how they move day to day and attempt to help them along a path. as an agilst I attempt to provide guidance and support for any given company finding their 'own' path. In a number of cases these choices will be what I recommend - but in a great number they will not. These other company(s) will need help finding their own path. This is when the agilist must become a person that helps to maintain the 'spirit' of the manifesto... attempts to provide guidance for the decision making process rather then dictating that things be done in a specific way.
Being an agilst is all about the philosophy
Being an agilist is all about the philsophy held - its all about the people involved. Its about nurturing the good processes and tools in support of the people and interactions. Being an agilist is not dictating that it must be some 'ONE MAGIC' way. People that attempt to make being agile all about being one specific way are looking for a magic bullet (a silver one perhaps). In the end however we all know there isn't one. Development of software is sufficently chaotic that having bumpers is better then knowing the one true path. Having guidlines rather then mandates... having a person who is willing to guide rather then dictate can be helpful. The aim is to move forward the best way we know how given the situation, I personally believe that being an agile organization is important to 'grow' how software is developed. I am an agilist in my heart, but certainly not the one that Mr. Appelo describes. I hope never to fall into that trap and become a cult leader for agile.
So I recently read an interesting article on the decline and fall of the agilists. I have to admit that it was an interesting read and it was not what I was expecting at all. I had decided on clicking the link that I was heading to read an article that was lambasting agile as a whole, and in specific the people who supposedly support and enable people to be agile in their enterprise. What I got was different. What I got was a point of view on people being far to rigid in their ideology, the agilists, the evangelists (supposedly) of the agile software development 'movement'. The point of view was decisive and accurate in my opinion, but not because agile is anything specifically different or the people who support it are any different - but because what I get out of it is an equation of an agilist to a terrorist or other extreamist.
Becoming an avid agile supporter
Over the years I have become a rather avid supporter of the agile methodologies. Scrum, XP and a few others have become the ways and methods that I would naturally choose to use when I attempt to do software development. These mthods are also the way in which I would hope that the business that I work for would choose to do their software development work. This of course is not always the case. Like most people I have worked for companies that have waterfall methodologies or other ways to do software development. These methods in some ways work for the companies that have adopted them. Sometimes they work very very well for those companies. They get alot done with their waterfall systems and feel that they have accomplished alot. It is my beliefe that even those companies could get more out of using agile methods. This makes me a supporter of agile, but it doesn't yet make me an agilist. It means that I would choose to attempt to talk the people I work with into giving agile methods a try - But I am not going to dictate that they need to do XP to be agile. More it is to describe that I am going to attempt to let people know what I have seen work in other places using my experience to try and allow a change to occur in the company. One that hopfully will get them to recognize a benefit.
The agilist in hiding
Does the desire to only use Agile methods make me an agilst. Possibly, but what I think differentiates me from the agilsts that are pointed out in the article is that I don't support doing agile in one set and unchanging way. One of the tenants of the agile movement is that the process has to be about the 'people' involved - the individuals and interactions before the processes and tools. You always have to start with the people. You have to look at what the people do, see how they move day to day and attempt to help them along a path. as an agilst I attempt to provide guidance and support for any given company finding their 'own' path. In a number of cases these choices will be what I recommend - but in a great number they will not. These other company(s) will need help finding their own path. This is when the agilist must become a person that helps to maintain the 'spirit' of the manifesto... attempts to provide guidance for the decision making process rather then dictating that things be done in a specific way.
Being an agilst is all about the philosophy
Being an agilist is all about the philsophy held - its all about the people involved. Its about nurturing the good processes and tools in support of the people and interactions. Being an agilist is not dictating that it must be some 'ONE MAGIC' way. People that attempt to make being agile all about being one specific way are looking for a magic bullet (a silver one perhaps). In the end however we all know there isn't one. Development of software is sufficently chaotic that having bumpers is better then knowing the one true path. Having guidlines rather then mandates... having a person who is willing to guide rather then dictate can be helpful. The aim is to move forward the best way we know how given the situation, I personally believe that being an agile organization is important to 'grow' how software is developed. I am an agilist in my heart, but certainly not the one that Mr. Appelo describes. I hope never to fall into that trap and become a cult leader for agile.
Subscribe to:
Posts (Atom)
