So as I have now become somewhat accustomed in recent months, words that keep showing up in my life trigger me to go into thinking about them and trying to understand what I can get out of them. The most recent of these words is "HELP". I spent 45 minutes talking about asking for help with some wonderful people in the Open Space session @ the Lean Kanban North America conference. The thoughts and discussion were amazing and helpful - and are incorporated in this post as well.
Help
The word evokes many images in my mind. I see pictures of someone in the water, unable to swim or unable to fight the current in the water and yelling for someone to come and help them. I see pictures of homeless people on the street with signs and cups seeking money from passer bys to get themselves their next meal or a warm place to sleep for the night. Pictures of friends and family members and the various things that they have asked for help with over the years flash by. While thinking about all those pictures it occurred to me that there is a picture missing that I think should be in the mix - and that is a picture of my co-workers asking for help. You see, in the context of work we don't seem wired to ask for or receive help from others.
Being seen as a burden
Asking for help in the work place is essentially to be seen as a burden on the person being asked for that help. This burden mentality seems to stem from the idea that asking for help is something that places one into a vulnerable position - and that vulnerable position then translating to a weakness that an individual shouldn't be showing at work. Why? Because if you are vulnerable or weak, then at work there is no way that you can possibly advance... you know, because you don't know enough of the right things. Suppose that you don't ask for help - you may still be seen as weak because it took you too long to learn or uptake something that so many people already know because they learned it previously at the organization. This too can reinforce a lower stature perception of people because everyone else looks with a bias - a bias based on having already learned the information which took you too long to learn. Asking for help means being vulnerable with someone. Asking for help means placing your desires out into the world and in most cases into another persons hands so that they can attempt to fulfill the request.
Everyone needs help sometime - even more so at work
So here it is, everyone will need help eventually - I think it is an inevitable fact that can not be avoided. People do seem to have a huge stigma against asking for help however. People who ask for help too often can be a burden, people who ask for help on simple things are seen as dumb, people who pander for money are seen as beggars and expected to go get a job. Some of those perceptions may be true - those people asking for help, MIGHT have been able to help themselves and the temptation is to assume they SHOULD have helped themselves. The assumptions around help generate a feedback loop that prevents seeing that someone might genuinely need the assistance. A trap is formed that essentially prevents people from being able to seek the assistance they need in the first place because we don't value people in our work place or in our society being vulnerable in the slightest. You need look no further than the things we tell our children when they get injured ("...Oh you'll be fine just get up and rub some dirt in it...") or boys when young about showing their emotions ("...stop sobbing, boys don't cry..." or "...man up you sissy...").
The human animal
Being vulnerable when asking for help not being a desired trait goes against what some would say is ingrained into our being in the world in the first place. The human animal is a pack animal, we want and need interaction and conversation by our very HUMAN nature. Too often we attempt to drive this part of ourselves into a corner however treating one another as soulless automatons that can do everything for ourselves. Humans are beings that need the touch, the nurturing, and the help of other human beings. Humans need to be connected to one another - help and help seeking is a way to take that care with someone else.
Practice makes perfect
Amanda Palmer has a TED talk that is all about the art of asking. Help and asking for it is something that can be practiced. People can practice knowing when to ask, what asking looks like and being gracious and generous when asking for the help that they need. In short - we all need to understand this and practice, practice, practice. We need to have the shared understanding of these 'help' interactions with one another. There needs to be the ability to see a request for help in all of its many and varied forms - being able to see it - REALLY SEE IT, would drive people to be so much happier than I think they are generally. Connections would be made - life long friends, a spark, a touch, were the connectedness we all know are there would show on the surface so everyone could see. I will be practicing this skill as much as I can in the near future... you should too.
Wednesday, May 1, 2013
Saturday, January 12, 2013
Date Chicken
Through out my software development career I have been trying to understand how things work, actively pursuing the thought processes that people use to make their decisions. I spend time asking questions about the hows and the whys of what I am asked to do and produce. This action, over time, has produced a decent picture in my head of how software development should work and in many ways how it should never ever work. I have been able to understand the whys of certain actions and requests but the one 'action' for which I have yet to totally understand is the idea of software development "Date Chicken".
Date Chicken as I would describe it is the propensity of an organization to want to assign a date to a project without understanding or going through an understanding of the complexities around what has been requested to be developed. Date chicken comes about due to not having enough of the discovery executed such that any date that can be provided has to be provided with a long list of provisos and comments/risks about what in the world at large has to line up "Perfectly" in order to meet the date that is being published. So software development teams are asked to produce these "Plans" that indicate that we can meet the date IFF (If and only if) everything else in the world happens perfectly. What happens next, every other team produces the same sort of statement about their ability to meet the date and the fun begins. Management from each team begins to execute on the "PLAN" that has been produced, they organize teams, and instruct people on what needs to be done and they wait patiently for the first 'date' on the plan to come up.
Here the Chicken part of date chicken takes over. Basically the teams continue to plod along towards the date until that first date arises and a team has not produced the things that they 'said' they would produce and everyone else involved in the project gets to point out that 'their' dates will have to slip day for day with every day missed in the development team at the front of the train. Hence the 'Chicken' in date chicken.
Why is this so hard for me to understand you might ask - every software company of any size seems to do this...
Its difficult for me for the following reasons:
1) The date is a lie, perpetrated by someone else and then taken as gospel, which leaves me feeling like my management doesn't want me to tell the truth, ever. Ok - the date is not entirely a lie - because there is an OFF chance that the needed software shows up on "time" with high quality, but so far I have yet to see that happen when this game of date chicken takes hold.
2) Because the date is a lie everyone 'RUSHES' to turn out the thing that they were on the hook for before their date arrives. In turn this produces software of lessor quality, with production issues, that turns out to be hard to manage and maintain.
3) #2 causes our customer experience to essentially suck, driving the customers to complain or look for service else where, making my company look like the best of the worst.
I do understand that sometimes the date is important, there might be legal reasons or contractual reasons that a specific software development item must be completed by a specific date. However - when there is no specific pressure in this way, I would much rather have my management say "I want to give you the time to make the software 'RIGHT', and I am willing to wait to make that happen."
I don't think it appropriate for the waiting to be forever, but do think that a management statement that says something like "I would like to see something demonstrable in one quarters worth of time." or even, "I am ok to wait to get this right, but I would like it to launch this year" to be fine statements that reinforce the please build this right rather than fast. As we get closer to actually delivering the software requested it is possible to provide a VERY high confidence number on 'when' we are going to be complete. The further away from done however the less confidence in the 'plan' being the right 'plan' and the date, so much more a lie.
In the end - none of this is in my control, but I sincerely hope that it will be at some point if I either end up in a position to make changes, or have my own company making software. Date chicken reinforces all sorts of really terrible habits and I would rather not participate.
Date Chicken as I would describe it is the propensity of an organization to want to assign a date to a project without understanding or going through an understanding of the complexities around what has been requested to be developed. Date chicken comes about due to not having enough of the discovery executed such that any date that can be provided has to be provided with a long list of provisos and comments/risks about what in the world at large has to line up "Perfectly" in order to meet the date that is being published. So software development teams are asked to produce these "Plans" that indicate that we can meet the date IFF (If and only if) everything else in the world happens perfectly. What happens next, every other team produces the same sort of statement about their ability to meet the date and the fun begins. Management from each team begins to execute on the "PLAN" that has been produced, they organize teams, and instruct people on what needs to be done and they wait patiently for the first 'date' on the plan to come up.
Here the Chicken part of date chicken takes over. Basically the teams continue to plod along towards the date until that first date arises and a team has not produced the things that they 'said' they would produce and everyone else involved in the project gets to point out that 'their' dates will have to slip day for day with every day missed in the development team at the front of the train. Hence the 'Chicken' in date chicken.
Why is this so hard for me to understand you might ask - every software company of any size seems to do this...
Its difficult for me for the following reasons:
1) The date is a lie, perpetrated by someone else and then taken as gospel, which leaves me feeling like my management doesn't want me to tell the truth, ever. Ok - the date is not entirely a lie - because there is an OFF chance that the needed software shows up on "time" with high quality, but so far I have yet to see that happen when this game of date chicken takes hold.
2) Because the date is a lie everyone 'RUSHES' to turn out the thing that they were on the hook for before their date arrives. In turn this produces software of lessor quality, with production issues, that turns out to be hard to manage and maintain.
3) #2 causes our customer experience to essentially suck, driving the customers to complain or look for service else where, making my company look like the best of the worst.
I do understand that sometimes the date is important, there might be legal reasons or contractual reasons that a specific software development item must be completed by a specific date. However - when there is no specific pressure in this way, I would much rather have my management say "I want to give you the time to make the software 'RIGHT', and I am willing to wait to make that happen."
I don't think it appropriate for the waiting to be forever, but do think that a management statement that says something like "I would like to see something demonstrable in one quarters worth of time." or even, "I am ok to wait to get this right, but I would like it to launch this year" to be fine statements that reinforce the please build this right rather than fast. As we get closer to actually delivering the software requested it is possible to provide a VERY high confidence number on 'when' we are going to be complete. The further away from done however the less confidence in the 'plan' being the right 'plan' and the date, so much more a lie.
In the end - none of this is in my control, but I sincerely hope that it will be at some point if I either end up in a position to make changes, or have my own company making software. Date chicken reinforces all sorts of really terrible habits and I would rather not participate.
Labels:
agile,
dates,
deadlines,
development,
games,
moral,
software design,
trust,
velocity
Subscribe to:
Posts (Atom)