So, as some of you all may know I am a proponent of agile methodologies. I have posted about agile in the past: here and here and possibly here - what you'll notice about those posts is that they are not specifically about agile, but rather about practices that I find important to doing my job well. This post is specifically about an agile practice and in specific about scrum and the practice of keeping a 'scrum board'
Physicality is king
A scrum amounts to a time boxed iteration of work. In this time box we are fixing the time, the money available (in the form of people) and we are allowing to vacillate the total amount of work that this particular group of people can accomplish (the features they will develop). The team when they start understands how much work they can complete and they commit to doing that many features from a list of features supplied to them. Then the work can begin. This work is 'tracked' as to its done-ness in either electronic form or in physical form. This should come as no surprise to anyone - but I am a large proponent of the physical scrum board.
The scrum board is a physical board used during the iteration to track the work (as mentioned above). Each story/feature gets a card on the board and is placed in the "ready" column. The other columns may vary depending on the team, our team has a "ready", an "in progress", a "done", an "accepted" and an "impeded" column. The cards are placed in each of these states as the feature is being worked on, meets its doneness criteria and is eventually placed into the accepted column.
What is great about this is being able to see and touch the cards or stickies. Doing this provides each team member with a sense of accountability that is not there when you attempt to just talk about features and work you are doing in the 'theoretical' during your scrum stand-ups. Having a physical board provides something that doesn't seem to be there in software solutions either unless you happen to have LARGE touchscreens (think Version One, Rally Dev, etc.) that provide that tactile, walk over and move the 'card' from one column to another, feel.
For me there is also something internally satisfying about really seeing items move from ready, to in-progress to done - Right there on the board. Without it, despite peoples updates, I feel a little lost during the iteration.
Additional (unintentional) Benefits
An additional benefit to the physical board is that is can be a great information radiator - transparent to anyone who happens by... they can see what you are working on, what you plan to be working on and what is already complete just by looking at the board. If an individual needs clarification they can always ask, but the board being out on the floor for everyone to see provides an ave for communication (despite being passive) that didn't exist before. It may generate questions, comments, or just plain discussion. Think about this situation - you are working on a feature in your sprint that interacts with another persons feature set (i.e. more then one team developing at a time) they happen by your board and notice what your team is working on and ask about how its going to integrate with what they are working on. Possible disaster averted due to this simple upfront conversation. Simply AWESOME.
A team can also use the physical board to add additional sprint metrics (information radiation) increasing the transparency with which the team is operating.
I fought the creation of this physical board for our team for a good long time - seeing what it can do to help the team, I am sorry that I fought as long as I did. The physical board seems to be an invaluable tool for the team and the organization at large.
PS: This physical board can also play into a Kanban type pull scenario - but may not include the specific columns mentioned here.
Sunday, July 26, 2009
Another Bob Update
Bob is now home from the hospital and is doing ok. Home care has been arranged for both Mona and Bob so that they have the needed support, at least in the short term for what is going on. There has been a hospital bed and an o2 machine delivered to the home and they are getting visits from the home care people on a regular basis to check up on Bob.
Bob is taking an appetite stimulant in an attempt to get him to eat more (it amounts to refined THC, the chemical in pot)... insert interesting munchies joke here. His intake of food and fluids however is still woefully slight. He is also been taken off the lasiks now that he has been released from the hospital. There is a good chance as well due to his insanely low blood pressure that they are going to remove the need to take his blood pressure medication as well. Which in all honesty is a good thing, one less pill to think about and one less chemical to float around in there. He remains on Plavix to help his circulation. His circulation is also poor and requires him to keep the house a little on the warm side (because he is consistently cold). Mo worked with him to help him layer clothing, etc. to help keep him warmer in his extremities.
This is prob. the last of the significant updates for now unless something bizarre happens or he worsens significantly.
Thank you ALL for your wonderful support, the checkins, the contact and well wishes. It was felt more by myself then it was for mo (as the calls generally came here to the house in NJ) but I will make sure to pass along all the well wishes to her.
People I would never have expected to send their care and good energies have done so in the past two weeks or so. It has been, enlightening and eye opening to me to see that. Thank you all for helping this family with support from yours.
Blessed Be,
Joe
Bob is taking an appetite stimulant in an attempt to get him to eat more (it amounts to refined THC, the chemical in pot)... insert interesting munchies joke here. His intake of food and fluids however is still woefully slight. He is also been taken off the lasiks now that he has been released from the hospital. There is a good chance as well due to his insanely low blood pressure that they are going to remove the need to take his blood pressure medication as well. Which in all honesty is a good thing, one less pill to think about and one less chemical to float around in there. He remains on Plavix to help his circulation. His circulation is also poor and requires him to keep the house a little on the warm side (because he is consistently cold). Mo worked with him to help him layer clothing, etc. to help keep him warmer in his extremities.
This is prob. the last of the significant updates for now unless something bizarre happens or he worsens significantly.
Thank you ALL for your wonderful support, the checkins, the contact and well wishes. It was felt more by myself then it was for mo (as the calls generally came here to the house in NJ) but I will make sure to pass along all the well wishes to her.
People I would never have expected to send their care and good energies have done so in the past two weeks or so. It has been, enlightening and eye opening to me to see that. Thank you all for helping this family with support from yours.
Blessed Be,
Joe
Wednesday, July 22, 2009
My Wifes Father - update for family.
Sorry about using my blog to do this, but this was the best way to get everyone I know informed as to the current state of affairs.
Mo's father has stage 4 lung cancer. His left lung has totally collapsed and due to the cancer in that lung (located in the pleura of the lung) the lung will not re-inflate. That lung's function (the left lung in Bob's case) is totally gone leaving the one good lung to do the work for him. The cancer Bob has is additionally in his liver. The cancer in the liver is essentially driving down Bob's desire to eat or drink enough fluids to keep himself 'right' while he is on lasiks to keep the one bad lung from filling with fluid.
On meeting with the oncologist this morning (7/22/09) - the oncologist did not recommend Chemo due to Bob's already diminished health and other pulmonary issues (PAD, etc) indicating that if Bob were more healthy to begin with then it might make sense because he would have some energy reserve to deal with the issues the chemo could bring on. He indicated that in cases such as this the bad side prognosis is 3 - 6 months. If chemo were an option, and Bob were prepared to fight he might get out to 10 months to a year or more but that would be the outside case.
In the end the picture is not rosy. We will be looking to organize in home care for him and Mona in the short term and further working on which long term plans and options are available to us all in order to make the best of a bad situation. The current state is mostly up to Bob - he has some control of his destiny here and can change his life style to make the most of what he has left. We are essentially in a 'wait and see' what he will choose to do. If this information significantly changes, please watch my facebook for further links and information.
Thanks,
Joe (On Behalf of the Campbell/Vercruysse Family)
Mo's father has stage 4 lung cancer. His left lung has totally collapsed and due to the cancer in that lung (located in the pleura of the lung) the lung will not re-inflate. That lung's function (the left lung in Bob's case) is totally gone leaving the one good lung to do the work for him. The cancer Bob has is additionally in his liver. The cancer in the liver is essentially driving down Bob's desire to eat or drink enough fluids to keep himself 'right' while he is on lasiks to keep the one bad lung from filling with fluid.
On meeting with the oncologist this morning (7/22/09) - the oncologist did not recommend Chemo due to Bob's already diminished health and other pulmonary issues (PAD, etc) indicating that if Bob were more healthy to begin with then it might make sense because he would have some energy reserve to deal with the issues the chemo could bring on. He indicated that in cases such as this the bad side prognosis is 3 - 6 months. If chemo were an option, and Bob were prepared to fight he might get out to 10 months to a year or more but that would be the outside case.
In the end the picture is not rosy. We will be looking to organize in home care for him and Mona in the short term and further working on which long term plans and options are available to us all in order to make the best of a bad situation. The current state is mostly up to Bob - he has some control of his destiny here and can change his life style to make the most of what he has left. We are essentially in a 'wait and see' what he will choose to do. If this information significantly changes, please watch my facebook for further links and information.
Thanks,
Joe (On Behalf of the Campbell/Vercruysse Family)
Thursday, June 25, 2009
I Hate Programming for the Web
So I have really been thinking about this for a while now. I have had the chance to work on more then one web based project. I have also had the joy of attempting to write a website for just TWO browsers (in a time when there were essentially two well known ones, IE and Mozilla). I have come to the same conclusion each time I do it, I HATE writing "applications" for the web.
State (NO, not friggin' New Jersey or Pennsylvania)
Gripe number one, the web SESSION. This little beastie is meant to turn what is normally a stateless protocol (http or https) into a stateful one. It is meant to keep track of things on behalf of the client, on the server, for the purpose of making mere html pages seem as if they are an application. This session information makes the loosely coupled html pages hang together as if they were a full blown application. Depending on your platform a programmer can store just about anything that they can dream up into the session and then call it back at whim. So you might ask - what is so wrong with the idea of storing some of this information? One - it’s a bastardization, the web was never designed to have such a construct. Some smart people made it up to solve the problem of doing more "interesting" things with web sites. Two - it can if not done correctly, completely screw up and make pointless any load balancing you may want to do to make sure your web servers can handle the load of all the people attempting to hit your site at once. Lets be blunt, if you wanted a cohesive state (engine or otherwise), why didn't you just write an actual APPLICATION?
Standards - We don't need no friggin' standards
Gripe number two - HTML/CSS. Look these things are supposed to operate the same way no matter what 'interpreter' you use to parse and present the results of the markup that is HTML. Both of these things are supposed to be standards that leave little or no room for interpretation on what it is that they are supposed to represent or what they are supposed to do when they are parsed out to make a web page. However, as any web developer will tell you, there is ambiguity in the standard that then gets interpreted by a browser programmer and as such leads to the different browsers doing different things based on the EXACT SAME markup and CSS. What a FRIGGIN' PIA. FOR REAL? What you get out of this is needing to maintain more then one CSS for the different types of browsers, or to maintain different CSS markup in the same file for similar purpose. This is all done in the name of making the ONE web page you just wrote look the same no matter which browser it is being viewed in.
Singular deploy
Gripe number three, while it is true that I get to deploy the application just once, as you can see above - I might as well have deployed the application one time for each browser type I wanted to support. My code is different essentially for each one. Granted - a lot of the logic is deployed once (i.e. the dynamic stuff I am doing behind the 'presentation' that is a web page) so I'll give anyone that one no questions asked. The other thing of interest here - will things like the Apple Application Store bring back applications on the desktop? Think about it - a super easy to use, easy to deal with installation and management mechanism that has what amounts to a micro payment to purchase in a great number of cases. VERY interesting if you could make that system work on more then just the iPhone/iPod Touch.
Security
Gripe number four. The web is a huge pain in the ass when it comes to security of what it is that you are developing. There are phishing attacks, XSS, CSRF, and god knows how many other varieties of remote type attacks. There is injection of a variety of kinds to top everything off. Add to all of this stuff that you have to defend against on the server side you also have the security vulnerabilities in the browser to contend with as they may make any of the other styles of attack that much easier. Desktop applications may have a number of the same types of problems, but at least I can count on only having to solve them in the application and not having to deal with accounting for both a browsers issues as well as problems in my own code. All this in the name of not having to deal with remote installation of code. Lets just acknowledge that installing software and managing packages has gotten a lot better then it was and consider it when new projects come around. But we don't we stick with deploying things as 'websites' because that is what EVERYONE DOES. I would still at least consider, in a closed circuit, if doing something new as a web app (i.e. internally for a company) makes the most sense before embarking down that path. Think Customer Service application and ask yourself if it makes sense to be a web application. Really?
AJAX - Flash and other ilk
SO - IN THE NAME of all this is freakin' holy, because we want things on the web to act, look and feel more like applications on the desktop WE ADD things like flash, silverlight, ajax etc. These things essentially provide a 'framework' window in which to - wait for it - WRITE AN APPLICATION! Are we all certified morons? We are all OK with this - it might as well be a java applet for cryin' out loud. All of these things break browsers in some very fundamental ways because the URL that renders the page is now a meaningless bit of fluff, the forward and back buttons which worked wonderfully when all the web was stateless are also now meaningless because they all work on the context of a page - and all the flash, ajax and silverlight items do not. Talk about ass freakin' backwards. Lets take a browser and put an APPLICATION in it rather then a web page. All these items are designed to get more control over something that was specifically designed to be so much more light weight and easy to use.
URL Shortners
Talk about compounding issues - now on top of everything else we have a class of services that shorten URLs so that emails and Twitters and other such 'social media' items don't have to deal with super extra special long urls links in text. HELLO? FOR REAL? I think Jeff Atwood put it perfectly when he pointed out that an href in html or url tag in bbcode or what have you were specifically designed to SHORTEN THE ACTUAL url so that you could use a single word as a link if you wanted. These url shortners add another level of complexity for finding things on the web, they can't be indexed, the can't easily be searched - they are not descriptive - and lets not even discuss what the hell happens when the 'site' that is doing this additional translation of short URL into the real one gets compromised. Now ALL those short urls are taking people to places that are installing malware. Awesome.
Face it - the web is a giant mess. Yet we all seem to still so enamored with it and everything must have a 'spiffy' interactive, loginable web presence. When are going to wake up and truly solve the issues of attempting to make web applications be actual APPLICATIONS? I dunno, but I do know its going to continue to be a pain in my side for a long time to come.
State (NO, not friggin' New Jersey or Pennsylvania)
Gripe number one, the web SESSION. This little beastie is meant to turn what is normally a stateless protocol (http or https) into a stateful one. It is meant to keep track of things on behalf of the client, on the server, for the purpose of making mere html pages seem as if they are an application. This session information makes the loosely coupled html pages hang together as if they were a full blown application. Depending on your platform a programmer can store just about anything that they can dream up into the session and then call it back at whim. So you might ask - what is so wrong with the idea of storing some of this information? One - it’s a bastardization, the web was never designed to have such a construct. Some smart people made it up to solve the problem of doing more "interesting" things with web sites. Two - it can if not done correctly, completely screw up and make pointless any load balancing you may want to do to make sure your web servers can handle the load of all the people attempting to hit your site at once. Lets be blunt, if you wanted a cohesive state (engine or otherwise), why didn't you just write an actual APPLICATION?
Standards - We don't need no friggin' standards
Gripe number two - HTML/CSS. Look these things are supposed to operate the same way no matter what 'interpreter' you use to parse and present the results of the markup that is HTML. Both of these things are supposed to be standards that leave little or no room for interpretation on what it is that they are supposed to represent or what they are supposed to do when they are parsed out to make a web page. However, as any web developer will tell you, there is ambiguity in the standard that then gets interpreted by a browser programmer and as such leads to the different browsers doing different things based on the EXACT SAME markup and CSS. What a FRIGGIN' PIA. FOR REAL? What you get out of this is needing to maintain more then one CSS for the different types of browsers, or to maintain different CSS markup in the same file for similar purpose. This is all done in the name of making the ONE web page you just wrote look the same no matter which browser it is being viewed in.
Singular deploy
Gripe number three, while it is true that I get to deploy the application just once, as you can see above - I might as well have deployed the application one time for each browser type I wanted to support. My code is different essentially for each one. Granted - a lot of the logic is deployed once (i.e. the dynamic stuff I am doing behind the 'presentation' that is a web page) so I'll give anyone that one no questions asked. The other thing of interest here - will things like the Apple Application Store bring back applications on the desktop? Think about it - a super easy to use, easy to deal with installation and management mechanism that has what amounts to a micro payment to purchase in a great number of cases. VERY interesting if you could make that system work on more then just the iPhone/iPod Touch.
Security
Gripe number four. The web is a huge pain in the ass when it comes to security of what it is that you are developing. There are phishing attacks, XSS, CSRF, and god knows how many other varieties of remote type attacks. There is injection of a variety of kinds to top everything off. Add to all of this stuff that you have to defend against on the server side you also have the security vulnerabilities in the browser to contend with as they may make any of the other styles of attack that much easier. Desktop applications may have a number of the same types of problems, but at least I can count on only having to solve them in the application and not having to deal with accounting for both a browsers issues as well as problems in my own code. All this in the name of not having to deal with remote installation of code. Lets just acknowledge that installing software and managing packages has gotten a lot better then it was and consider it when new projects come around. But we don't we stick with deploying things as 'websites' because that is what EVERYONE DOES. I would still at least consider, in a closed circuit, if doing something new as a web app (i.e. internally for a company) makes the most sense before embarking down that path. Think Customer Service application and ask yourself if it makes sense to be a web application. Really?
AJAX - Flash and other ilk
SO - IN THE NAME of all this is freakin' holy, because we want things on the web to act, look and feel more like applications on the desktop WE ADD things like flash, silverlight, ajax etc. These things essentially provide a 'framework' window in which to - wait for it - WRITE AN APPLICATION! Are we all certified morons? We are all OK with this - it might as well be a java applet for cryin' out loud. All of these things break browsers in some very fundamental ways because the URL that renders the page is now a meaningless bit of fluff, the forward and back buttons which worked wonderfully when all the web was stateless are also now meaningless because they all work on the context of a page - and all the flash, ajax and silverlight items do not. Talk about ass freakin' backwards. Lets take a browser and put an APPLICATION in it rather then a web page. All these items are designed to get more control over something that was specifically designed to be so much more light weight and easy to use.
URL Shortners
Talk about compounding issues - now on top of everything else we have a class of services that shorten URLs so that emails and Twitters and other such 'social media' items don't have to deal with super extra special long urls links in text. HELLO? FOR REAL? I think Jeff Atwood put it perfectly when he pointed out that an href in html or url tag in bbcode or what have you were specifically designed to SHORTEN THE ACTUAL url so that you could use a single word as a link if you wanted. These url shortners add another level of complexity for finding things on the web, they can't be indexed, the can't easily be searched - they are not descriptive - and lets not even discuss what the hell happens when the 'site' that is doing this additional translation of short URL into the real one gets compromised. Now ALL those short urls are taking people to places that are installing malware. Awesome.
Face it - the web is a giant mess. Yet we all seem to still so enamored with it and everything must have a 'spiffy' interactive, loginable web presence. When are going to wake up and truly solve the issues of attempting to make web applications be actual APPLICATIONS? I dunno, but I do know its going to continue to be a pain in my side for a long time to come.
Wednesday, April 22, 2009
It is the people, stupid...
There has been a great deal of conversation in the world at large about different ways in which to perform work (i.e. processes for tracking and getting things done). There are many and varied ways in which this has been attempted - processes such as WATERFALL, SCRUM, AGILE, CMM, RATIONAL... all of which are about the same thing, attempts to make software development managable and predictable. Most of them however fail at their attempt for a variety of reasons, but I wanted to take a minute to focus in on one aspect of why they fail - The people involved.
The People
It should go without saying that process is really only a small part of how software development in any company gets done or executed. The process is in place to attempt to guide and assist when questions come up or there are issues found during development. These problems can be with the intent of a feature or sometimes even with the 'code' implementation itself. In this respect each one of the processes above meets the need - they can all provide some level of guidance for an individual or group attempting to develop software. However with the exception of the 'agile' stack a good number of them miss the point... process is not helpful in dealing with people. Real people are doing the development and real people are hard to predict for over time.
The Process
The People
It should go without saying that process is really only a small part of how software development in any company gets done or executed. The process is in place to attempt to guide and assist when questions come up or there are issues found during development. These problems can be with the intent of a feature or sometimes even with the 'code' implementation itself. In this respect each one of the processes above meets the need - they can all provide some level of guidance for an individual or group attempting to develop software. However with the exception of the 'agile' stack a good number of them miss the point... process is not helpful in dealing with people. Real people are doing the development and real people are hard to predict for over time.
The Process
Every software project I have ever been involved with attempts in some way to be predictable in its delivery of items. Items for the project may include documentation, code or a myriad of other things but in general the 'what is delivered' only matters in so much as this discussion being about software development. Some projects focus on Dates (not these or these) the times during the project on which certain "items" within the project will be delivered. New functionality or even the entire system development might be driven by these dates. Sometimes these magic dates are called 'Milestones'. These milestones are points in the project when supposedly major portions or steps of the project will be considered done (most of the time without a clear definition of what 'DONE' is). Gantt charts, carefully laid plans, deadlines, etc. etc. etc. all put in place to suffice a process that in the end is attempting to control and make predictable the delivery of software. All are attempts to stay in control of something that in most cases by its very nature is 'out' of the control of the person doing the planning.
OK - so maybe that last statement is a little harsh. Lets be realistic though, I am sure everyone reading this blog has been on one project or another where the schedule, deadlines and all, in addition to what was 'TO BE DONE' in the given time frame was essentially dictated to them by either management or a project/program manager that was being told to essentially get 'X' thing done by 'X' date. Addmitedly the world is full of deadlines - and some deadlines are needed, but having two of three sides of a triangle dictated doesn't leave alot of room for the 'last' variable to move around alot.
But in the end we plod forward, bad news is supressed because no one wants to hear it... and then everyone ends up on a DEATH MARCH to the end of the project. Everyone gets irritated because the work they may be doing is not of the highest quality (in some cases even mediocre quality) and everyone feels dirty about not adhearing to best practices when it comes to development. There are no unit tests, the documentation is shotty - and the delivered "thing" is held together with spit and bailing wire.
MOST Processes miss the point its not about the deadlines, its about the people - and maximising what they can do to get the most delivered possible with the highest possible quality.
Agile and people - some implementors miss the point
Most processes I have worked with and in focus on variables that most people think of as being easily controlled. Things like the delivery date or the number of people working on the project. It is true that these things are easily modified and very measureable but the item that most project/program managers don't consider is what happens when you don't fiddle with those things but instead work to fully understand the work and how much of it the development team can actually accomplish CORRECTLY.
How gaining this knowledge helpful or different from what most methodologies do and tout? First, having this understanding is a very agile practice in my mind. WARNING BROAD SWEEPING STATEMENT FOLLOWS: Usually project and program managers understand what needs to be done, but they don't understand the constraints in the existing software or sometimes even the existing systems if we are discussing full life cycle systems development. This is where controlling the work list is important and priority is KING.
Agile processes are all about knowing the priority work list and what the people CAN accomplish. In essence it is all about the people involved (project and program managers included in the 'people involved'). Agile is about knowing what the people are capable of doing, producing a measurement of that (velocity) and using it as a way to understand how much work a given group is capable of in a time box. This turns the tables and empowers the people involved to push back and say no to things because they have a definative measure of what they are truely capable of accomplishing well and correctly. That is not to say that on occasion some teams will go above and beyond, but that doing so becomes a CHOICE and not a MANDATE because the speed of the team is no longer a variable and if it is - it tends to be a very predictable one.
Agile is all about the people. People understanding themselves and the people they work with. Understanding what each one of them does best and putting those things together to get a deployment of working software out the door. Agile is about making the software delivery as predictable as possible. Agile is about adding the right process to the people to allow for that predictability. Agile is not about imposing or over imposing but focuses in on the people involved and helps them with the right 'touch' and guidance, the right process. In that respect - agile process is the hippy of the software development world - one that I am more then willing to embrace because it is the people that matter. Without the people - nothing gets done and if you have a process that works well with the people and not counter to them I would argue you are going to get alot more done with people being generally happier about it.
Thursday, March 26, 2009
Intra-Office Male Genitalia Mesurement
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.
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.
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.
Sunday, February 1, 2009
Process, progress and equality
So a friend of mine Mr. Fury recently wrote a little post on "Process" (Yup, thats capitol P process). Specifically, since he and I work for the same Big Co., we was writing about a wonderful framed master piece that hangs on a number of walls at Big Co. This art piece, which he points out, is meant to be inspiring and up lifting is a bit off the mark and is a bit mocking rather then inspiring and uplifting. This picture says simply "Process = Progress", I think attempting to indicate that we are not moving forward @ Big Co. unless there is a process in place. It may also indicate that progress can not be measured without a process - but I am not sure that is the direct meaning.
Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).
The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.
In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.
I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.
The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.
Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.
Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).
The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.
In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.
I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.
The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.
Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.
Subscribe to:
Posts (Atom)
