Tedbets, the only way to bet your friends !

Saturday, November 23, 2013

I’m happy to see lots of people supporting and stating the obvious about this topic. Though I thought I’d add my 2c to the demise of this all to common evil of open offices.

They are typically favoured by individuals who like to interrupt others, and also by those who look to short term visible costs. Open offices are likely the single biggest cause in companies of:

The lost of human happiness

The lost of team/individual effectiveness

The lack of success of companies and projects

I rank them in that order for importance as well, as that’s the order I’ve typically experienced them being absent in successful projects. I believe the mental state of the members of the team, and the collective teams health is a core (if not the primary) factor in successful outcomes.

It’s good to see the academic community supporting (with research) what many have felt and known to be true for so long [1],

I’ve spent many years in different office environments, when I haven’t had the luxury of working from home (where I’m most productive, by far) so have experienced a range of the options. I’ve turned down several very senior positions throughout my career, and common factor in each one was the company had - and actually supported the use of - open plan offices.

While hard to quantify, I wonder how many companies looking for good people are making them run for the hills as soon as they see the work environment.

While we are social creatures, we need our own space and to not feel the need to constantly defend it. If we are busy defending, we can’t relax and get on with focusing on what we are supposed to be doing. Books like "Quite: The power of Introverts in a World That Can't Stop Talking" is a good read for this, for the introverts amongst us.

The common perception of interaction is physical interaction, people talking to each other. But more common and less visually detectable is digital interaction. Given the technological connections that have been present for many years, having a number of gChats going, Skype open, ninchat, etc is not uncommon.

Personally this is a large part of how I work, and it’s very good interaction, it has two main benefits. Firstly I can set a status of DnD (Do not Disturb) to communicate to others I’m focusing or in flow, the other visual clue if I’m in an office is wearing headphones. Secondly I can just logout to manage individuals who can’t manage their own boundaries or respect others (see extrovert ...).

2. The promote an open culture in the company

Far from it, they actually decreases healthy interaction by increasing defensiveness between individuals, along with stress & resentment of having to tolerate the environment.

There are a bunch of links at the bottom that cover this topic, so I’ll not cover that aspect in this blog post.

3. They are cheaper

My first thought it is “define cheaper” … personally I think longer term and a bigger picture than a few months. Though what is typically meant by HR and logistical people, is you can get more people in per square foot. Much the same way industrial farming abuses animals … and look how that turns out for quality and happiness.

I would estimate from personal experience I’m around 50% less productive in an open plan office (and that’s being really generous). Even with the argument of “You do pretty well, what are you complaining about” it’s worth remembering that this isn’t about what a person produces, it’s about the difference in what they can do in a good environment vs a bad one.

a.k.a. “If you think I’m good now, you should see me when I’m able to concentrate…..”

So using the 50% experienced-thumb-in-the-air rule, lets see what happens with 10 people in an office. I’m going to go from personal experience relative to the Vancouver, BC market, and using www.payscale.com. The median pay (for the whole team) is $55,000 for a technically focused company. Being roughly half a million just on salary (before employer costs).

$250,000 a year down the drain.

$10,000 extra a month to move to an office with some offices and good ergonomics (and people working from home if they want) and you actually end up saving $130,000 a year and have much happier people.

Also, I don’t believe people can operate at 100% all the time, or that that should. Taking a break and some time to check out lolcats before the next task is important (mandatory I believe…..).

Talking of happier people, I’ve not factored in sick leave and attrition due to poor environment as well. Even having to call the days people take off to be able to tolerate a typical work environment “mental health days” should tell you something.

So no, open plan offices are not cheaper, at all.

So what to do

As with just about all things in life, it’s about balance. I’m not advocating silent corridors of closed doors, as that is absurd as the open plan office are in the first place. It’s just the other end of the spectrum.

As Gensler’s survey[3] mentions :

“It takes collaboration to quickly move ideas in a competitive knowledge economy. Fluidly shifting between focus and collaboration is how work flows today.“

They use the term “balanced workplace” which is the key, you need both sides of the coin. How you achieve that is the trick.

Achieving that means looking at all the dynamics and interactions, just because people aren't physically talking doesn't mean they aren’t interacting and communicating.

I communicate with my team a lot though www.github.com and Skype, as it has more context, is more convenient and ultimately is more respectful of their choice to be focused or opt in to communicating. Also when I forget something I don't have to ask again, I go and search. Though I enjoy collaborate meetings and time around the whiteboard solving problems just as much, but there is a time and place for both.

I appreciate this is an alien concept to individuals who thrive on personal interaction, and attempt to undermine - inadvertently for the most part - introverts abilities to focus as they think they are being rude or ignoring them. I’ve lost count of the times I’ve explained to sales people how jarring it is for a developer being pulled out of flow for a question that could of waited.

I believe a mixture of areas in a work environment is ideal.

So there can be the library quiet areas where people can focus and the interrupters have to respect that. The flip side being is that people can’t hide in there all day! In the absence of being able to do that in a physical way (separate spaces), have periods of the day that are for focus work, and others that are for social. Enforcing that will seem draconian and unnatural to begin with, though it will evolve over time to something that works for all. The initial effort is just to correct the balance.

For all the individuals who are harbouring the thoughts of “if I can’t see them how do I know they are working”. Firstly, get some therapy for trust issues …….. secondly if that is the case your hiring criteria is the issue, and ultimately it’s about the outcome and quality of their work. Not that they are treated like battery hens on a clock under a watchful eye.

The members of my team could be on the moon, in their pyjamas working at 3am if they like …. if that’s what works for them, when they need to focus to get things done - awesome - I'm happy they figure out their formula for getting things done.

And when the time calls we communicate as a group as we need to, when we need to.I say:

Hire professionals, describe the challenge and direction, then trust them, get out of their way and focus on facilitating and support the outcome of the project. Being mindful of their environment physically and digitally while working is part of the facilitation balance.

Getting this right is the balance I think is key, try to focus on and promote.

Sunday, August 7, 2011

While I'm using Drupal on some projects as an example, I'm not singling Drupal out for criticism for the sake of it, and not ignorantly either as it's the CMS I have most production project experience with (opposed to vBulletin, though when I worked creating that, it was a forum - and not trying to be anything else).

The purpose of this post has to do with my thoughts on : Choosing the right tool (and starting point) for the job.

Knowing not only why, but that you have done so, as no project or pieces of software is ever "done" till two things happen. Firstly when it's stopped being worked on, and then it will last as long as it is robust, and secondly when the server is turned off.

Everything from conception up to the first stage is "the development of a software system", releasing it or putting it on a server is just one part of that, typically when customers (hopefully turn up and) need supporting. It's also usually at this point that if you have community engagement and it's manage that your system can be lead and developed for the needs of the community that want and use it. Release too early and you wont have enough of a vision or direction, too late and you'll of cut off all kinds of possible user input. Also someone else might of beat you to market.

So what does this have to do with a CMS like Drupal and a Framework ?

Much the same difference that buying Ikea furniture has with buying precut wood and understanding the tools. As always there is a time and place for both, though two typical things happen when you have a CMS build vs a framework build.

First ....... explosive module bloat. I can't remember the number of times I heard the conversation :

"Oh I just want to do this one simple thing"
"It's OK I know of one module that does that, though you need five other to support it, but hey that's OK".

A few weeks later you have two hundred SQL queries per page load and 70 modules, just for an original request of one simple feature. Given that it's very likely that you're relying on 3rd party modules, you are now at the mercy of the erratic OSS winds for the up keep of the module(s).

Typically you'll never get the exact behaviour you want as any generic module is built to what ever the requirements were at the time the author write them, so likely a compromise to what ever it is you need now.

The typical approach I've seen to this in the vast majority of Drupal projects is "Time to do some integration work" ....... also known as ....... "Just keep hacking it till it seems to work" i.e open window throw out quality and stability and upgrade path, close window.

When this approach inevitably grinds to a halt you end up seeing the "Need a rock star Drupal developer for final 10% of project" posts on job boards. At this point you know it's a spaghetti nightmare ....... the irony of why not get a "rock solid engineer" to begin with is never lost on me.

Second thing is maintenance, or full life cycle support. i.e. once you get to market and have to care for and evolve the system, you can't. You're so hacked into a corner the technical debt overwhelms anything you can do against it. This is typically where inept management will start to blame developers for their choices when faced with the symptoms of a system in crisis.

-----------------------------------------------------

So what goes wrong ?

1) Due diligence

A software system as we've seen is a journey. Even with my recent encounters with the games industry and individuals claiming something is "done" and should be launched, it's not, there will be patches and updates. They are just trying to minimise the latter and try to paint it as failure opposed to understanding that it's part of the process.

Obviously embedded systems in medical equipment (as an example) is a different story, though it's very much the process and understanding which is present that achieves that level of quality, so actually supports my argument.

So ensuring that you (as a client) know what the options are, or as a developer are skilled enough to communicate that to a client is essential. If you aren't go work for someone who is, and learn from them.

Are you building a product or site to depend upon or a site for a weekend event that is going to be decommissioned in a few days. One needs good foundations and the other needs speed. Understand that rapid prototyping is just that, prototyping, it's done for learning (as is the blend of development by exploration) not delivery.

Typically what happens is that speed is chosen and high quality is assumed, opposed to the reality which is the other way around.

Speed in this context is the wrong word as well - it should be velocity as that has a direction which is important and it encompasses the vision of an outcome as well as time.

Answer - Don't just do something - think first - where is this going and what does it have to do.

2) Been told vs choosing

Requirements and understanding of the problem, then the tools not the other way around. I've met with teams that seems to think that there is a one word answer to every project (i.e. Drupal). Open blog site ? Drupal ...... image upload site ? Drupal ...... hot metal device for flattening my freshly cleaned clothes ..... you guessed it, Drupal.

Fanaticism leads to blindness, not just in politics and religion, but in engineering as well.

Answer - Realise you're in a very diverse world, and that's a good thing. There is no one answer to everything how ever hard you want it to be, as every situation is different.

-----------------------------------------------------

When to use one over the other ?

By taking the time to understand, how well do you know what it is that you want to achieved, what are your time scales and will this every have to be maintained.

Given the 80/20 rule applies to most software projects using something like Drupal do do 100%, getting the 80% done quickly and then hacking yourself into a corner to get the last 20% isn't worth it ....... given that you can do the 20% with a half decent frame work anyway.

Thursday, March 3, 2011

Creating New Sugar CRM Graphs

I've recently been working on a project that required some custom chart additions to SugarCRM. At time of writing the project is using the Community Edition, which according to wikipedia has 85%~ of the code base that the Professional and Enterprise editions do.

I think I'll have to side with Dan Farber from CNET with concerns over how SugarCRM uses the term Open Source - it's not really. Especially considering that I'm working with the charts module, which is one of the main pieces which has been removed from the AGPLv3 license in Sugar 6 (the latest edition).

While being hindered by a lack of documentation and examples with regard to charting, i.e. the main way you view all the data in your system, I've had to reverse engineer the system that is being used. This would appear to be common in various areas of CE, i.e. it's entry point bait that gets you going on a project - then you realise you need Pro or Enterprise - to deliver on the project.

Make sure you have all the functionality asses before you start on a project with this, and if you can't find how to do something in less that two minuets, assume it can't be done.

I think a better route would of been to use something like CodeIgnighter and jpGraph and build a custom reporting interface. Opposed to using the limitations of the Flash graph player that is offered by default. Then again if your off down that route you're already - outside of the bounds of the system - you should be looking at the whole project and what fits best, as it might not be SugarCRM at all.

Though this blog is about explaining how the parts I understand interact, and then how to work with what is there.

Overview

SugarCRM uses the concept of modules, and modules can have "Dashlets" which is what you can see and interact with on your Dashboard. For this example we'll be in the directory :

/var/www/modules/Charts/Dashlets

Fairly self explanatory so far - the dashlets directory for the charts module.

There are several predefined ones in there.

Ultimately the Chart Dashlet is a Flash player that is given the URL to a PHP generated XML file, which then renders it as the graph you see.

The files in a Dashlet folder are named as per the folder and class name (as that's how Sugar finds and loads the relevant classes).

So for our example we'll have :

/var/www/modules/Charts/Dashlets/AccountsTotal

A chart to show the total accounts we have per month.

Inside that directory there are 5 files (yes 5 .....) that make up the data/functions for the chart :

{name}.data.php

{name}.en_us.lang.php

{name}.meta.php

{name}.php

{name}.tpl

So for our chart we'll have :

AccountsTotal.data.php

AccountsTotal.en_us.lang.php

AccountsTotal.meta.php

AccountsTotal.tpl

AccountsTotal.php

Just copy one of the existing directories and files, and then rename them.

AccountsTotal.data.php

This will contain the search fields for the chart, the popup when you click on edit to choose a date etc. For now just rename the first element of the Array to the class name so Sugar can load it .

$dashletData['AccountsTotal']['searchFields'] = array(
...
...
);

AccountsTotal.en_us.lang.php

Same again here, it's just a tokened language file, so rename the key to the class name

$dashletStrings['AccountsTotal'] = array(
...
...
);

AccountsTotal.meta.php

The meta file is used (for what we're concerned with) by the Dashlet selector - the pop up where you select what Dashlets you want to add to your Dashboard. If you want to check the options the images are stored in :

/var/www/themes/default/images/

i.e. icon_Charts_GroupBy_32.gif

AccountsTotal.tpl

The template file you can leave for now, it's the HTML for the configure popup, i.e. where you choose the dates to feed to the graph logic.

AccountsTotal.php

This is the main file for the graphs, the C of the MVC world.

This is a class file that extends the Sugar class of - DashletGenericChart - so rename accordingly.

class AccountsTotal extends DashletGenericChart

The constructor and displayOptions can be left, and just call the parent methods. The $options that are passed to the constructor are the details that you set in the search fields.

Now to get the data & construct the XML I have deviated from Sugar, as after decompling the SWF file and going though the XML generation (that is string building opposed to any use of native PHP XML) I found a much easier and quicker route to getting the job done.

There are also various bugs and inconsistencies around :

$sugarChart->sortData();

So I didn't use it, I wrote my own XML handler available (here), it constructs the XML using native PHP functions to do so.

All that remains is to get the data, and sort it, getData() seems to work, so we can use that.

$sugarChart->getData($this->constructQuery());

This places the data into an array :

$sugarChart->data_set

All that remains to sort the query data into rawData then use the new XML class to build the desired outcome and then pass it to the usual Sugar methods for saving the XML and returning the HTML to display the Dashlet.

Sunday, January 30, 2011

I've always been interested not only in the specifics of software itself, but also in the method of how software is created, and what surrounds it. That being teams, leadership, management, external factors, business constraints and likely most importantly the sociology and psychology of creation.

More of a holistic systems view of the whole process I believe. My degree and area of interest is Software Engineering Management so some of the how as well as the what.

I realised I've found myself explaining the same topic repeatedly to people in a business context (i.e. suits) who don't develop software, but who interact with people who do.

So I thought it best to just write it up, then I can direct future people I encounter who ask or need to understand it to here. Also share my thoughts and hope to elicit ideas and experience from others, as this topic really interests me.

The topic is that of the psychology of a developer, when operating a maximum capacity (relative to them). What's it like, how do people get there and what are the good and bad aspects of it.

Typically I find organisations (mid level managers usually) expect and demand maximum output of developers at all times, in any conditions and with no support. Any failure to achieve this with a (typically) negative or unsupported environment is wholly the developers fault (see my other post on burnout for what happens then !).

The usual analogy for that situation is a Dickensian work house, where more hours and faster (more frantic speed) should equate to more output.

Obviously nonsense, though still lots of places like that about, and it's all of our responsibilities to eradicate them.

The Mind Set

The mind set of a developer when at maximum level of creation and development is covered by an area of : Positive Psychology. in particular "Flow".

Introduced by Mihály Csíkszentmihályi it is a well accepted description and understanding of the mental state of individuals, who are wholly engaged and passionate about an activity they are doing. There have been many posts on passion in developers being one of the main things, and I agree (we just need to educate recruiters now).

The wiki page for Flow covers a lot of the general aspects of the topic, so I'd like to relate/translate that to software creation and teams. The page does mention professionals and references Hack Mode and The Zone.

One way that I attempt to explain the state of being in Flow to people who haven't been, or can't understand it in a developers context is to reference Star Trek Generations. While a techie film itself, it's still more likely to have been seen by someone I'm explain to, than them reading psychology just for fun.

In the movie there is a character, Soran (Dr. Tolian), played by Malcolm McDowell (yes, I know he must be the evil baddie he's English .......) who is attempting to get back into the Nexus.

The Nexus is described as :

"The Nexus is an extra dimensional realm in which one's thoughts and desires shape reality."

This is a fairly fanciful analogy I'll admit. Though there are a lot of comparisons of being in an place/zone where everything you can think of just happens, where you laugh at test units and write and re-write swathes of class/functions in moments. Code of pure gold flows from the keyboard etc.

And it's a true pleasure, not only are you creating at a pace that would make accountants shiver when calculating your hourly rate vs effectiveness.

Though farfar more importantly, you are doing what you enjoy and are feeling the rewards of creativity near instantly. Maslow would likely describe you as in a state of : Self-actualization.

For me there is no reward, monetary incentive or management manipulation that can either induce this, or surpass the reward of experience itself (though for sure I'll accept a health pay check/equity for it when it does happen !).

I'm not sure I'd destroy a planet and it's people (as Soran was prepared too), to get back to it on demand, though I'd think about it ........

Though it raises two very interesting points for me :

How do you get there ?

How do you stay there ?

Allowing it to happen

Personally (and in the research I've done) the path must include a level of passion and/or very high engagement. This typically can't be demanded by management or forced onto a person.

It's much like (my aversion to) the TV self-help demagogues, who are forever telling (prescribing to) people how to live, opposed to the people creating and embodying the answers for themselves.

In counselling, it's called client centered. Zen and other eastern philiosphys continually talk about the energy and power within, and that's where the source of a lot of this comes from.

The main thing that management, and more suitable team facilitator(s) can do, is create and protect the environment to allow the developer(s) to reach this state. Once that is in place, communicate the challenge/goal and desired outcome, then stand back and get out of the teams way. Ego is the typical reason this doesn't happen as weak management has to feel "in control". A shame, though a common human failing.

Attaining Flow is a skill and ability, it comes from engagement, curiosity, the challenge and having the skills to overcome the task.

Meaning you have to be good enough for the challenge, that you're not battling with your tools. Be that, a programming language, the server configuration, understanding of a protocol etc.

So the things needed are :

A sufficient challenge, it's engaging and enticing

You have to be "up for it", personal motivation and external encouragement

Have sufficient skills enough "to take it on", and not be over whelmed

As per the diagram (I grabbed from wikipedia) :

Staying there for the individual is a matter of practice, of concentration and immersion. Much like practicing to meditate, I remember when I started meditating I would last two maybe three minuets and my mind would wander, years later and half an hour is no real challenge within itself (more so the motivation to actually begin now !).

Staying There

I find the single most important piece in a development environment that is lacking, is the understanding of the other individuals (hence writing this so I don't have to keep repeating myself).

It can take any where from 15-30 mins for an individual get into this state, and become engaged and start producing while there. The constant inquiries of "Have you done it yet" or "Lets all have a meeting to listen to me talk" is doing nothing but breaking that lead in time, and hitting the reset switch for getting back into it. I'm all for communication, of course, teams and organisations need it. Though when necessary and in context.

I think the only thing that is more disruptive (and mentally painful) from being stopped getting to the Nexus ....... err a productive state of mind ..... is being ripped out of it once there. It's so jarring I've contemplated drowning people before ..... though have put it down to their ignorance opposed to malice.

Nerf guns in an office are for play time ........ not 24/7 while people are trying to work.

Shouting into phones in (or at people on the other side of) an open office (which themselves are very negative to focusing) isn't helping.

Typical management is driven by interruption, Jason Fried 37signals has talked about interruptions lately, and way pre-dating him is Peopleware that covers it in much more detail.

Thoughts

Personally I become very frustrated when subjected to the kind of environment that stops productivity and high quality productivity at that.

I (and just about all developers I've ever talked to) can do far more in 4 Flow hours than 8 of typical office, and it's far better for everyone involved. Let alone the future as the software is of a much higher quality : think lower Technical Debt.

So why not let it happen and protect it ?

As ever take care of #1 and have a thought for others trying to get things done.

Tuesday, January 18, 2011

I recently saw a few tweets pushing a piece entitled : When Smart People are Bad Employees.

Luckily the sense of many comments shone though, and the author was eviscerated for what appeared to be short sightedness, poor understanding of behaviour and basically poor posting.

Though it did get me thinking about the amount of confusion and reactionary behaviour there is out there by this kind of management, which that author appears to be representative off (thankfully small and diminishing in my experience, though still present).

Another case of trying to enforce "us and them" I'm right your wrong, opposed to "we".

We're all human, and we're all fallible at times.

I found the majority of this kind of behaviour and approach comes from a lack of trust, of oneself mostly, and then the team. A fear response to attempt to control, opposed to having the will power and self control to resist such behaviour.

(There was another piece I saw on : Managing Nerds, while better and nearly saving itself with some tongue in cheek humour, it was ultimately "us and them" tactics as well as being simplistic and condescending)

Hence why I'm going to review some of the points give my take on what is going on. Then actual options for how to deal with it, opposed to the original advice of :

"Put up with it, blame them, then fire them" .......

Behaviour

Though firstly, I think it is valuable to separate behaviour and the person.

One of the over whelming messages is the original post, is that you judge people and describe them from their behaviours. I suggest that you don't and you define and isolate the behaviour that you find challenging, and see it as your experience of that behaviour instead.

Keep the faith that most people are positive and want the same things, just some have trouble expressing it or communicating frustration.

Once you have identified the behaviour and stopped trying to judge and blame the person, you can do the first best thing, and that is asses yourself.

There are volumes written yearly akin to : "What pisses us off, tells us about ourselves" etc. I could quote all kinds of philosophy, but you get the idea.

Is the behaviour you are experiencing out of place or inappropriate, or is it your reaction and perception that is magnifying it ?

As with just about anything in life, self awareness is key and also as elusive as it is time consuming to develop, though obviously well worth it.

If possible, consult with someone who's there that you trust. Possibly a colleague or team member. Remember it's by way of understanding are things how you see them, opposed to an opportunity to complain or try and build sides.

Communication

Just about all issues (of this kind) I've come across come from poor communication (and expectation), be it typical or deliberate.

Project groups are collections of people attempting to get a common goal achieved. Though within that you have collections of individuals who all see the challenges at hand in a different manner (which is a real strength by the way).

As well as being people, and all that goes with that themselves.

The usual kind of approach for management that reports all these difficulties is mandating and dictating to a group, how to solve the issue as they see it.

There are two fundamental issues here. First, the team will solves the challenges, that's what project teams do, when allowed, and support by facilitation. So focus on the issue, not trying to tell people who likely know better than you how to do it.

This is where trust and respect come in, not the iron first of weak managements "I'm in a suit and have a big title, I have to tell you what to do, what else am I hear for" (that topic I'll leave to Dr Paul Thomas).

One of the most important things to do is communicate, and the most important part of communicating is listening, not talking.

If you are experiencing what you perceive to be negative behaviour by people who are "negative" or "questioning you all the time" .......... find out why!

Resistance is typically a good thing when it's about a project, as someone who can see something you can't is likely trying to tell you something.

Control

If you are from the Dickensian school of management (lets call it "the 80's" and you have a huge Motorola mobile phone you like to shout into in the middle of the office), then control is going to be second nature. Anything Zen is going to involve "Asian people in silk pyjamas waving their hands about".

(As it is I rather like Tai-Chi, it's taught me lots about dealing with energy, negative or positive, and how to go with the flow and re-direct a lot of the time. Also the costs of going head to head, Yang vs Yang, feeding anger etc.)

There are times when legitimate control and power make sense, for instance a parent physically stopping a child walking into a busy road. Another typical one is the military, because of chain of command (though even there there are caveats for disobeying certain orders).

Now unfortunately I've seen groups that are run at one extreme or the other, a crèche or a military dictatorship.

I'd suggest will intelligent professionals, both are pointless and counter productive.

Though what is apparent to me, is when you have a clash of expectations, within the team. A lot of managers attempt to actually run and direct individuals within a team, i.e. that age old term : micro-managing. The vast majority of IT/software people are going to be resistant to this as they know how to do the job and need support and facilitation, not a condescending head master.

So from the managers point of view, they are resisting and being difficult.

A common and unfortunate mistake, also when done in the context of "I'm more senior, I must be right" there can only be one assumption.

The key here, once again, is the self awareness of what is going on, and what is more important :

Being "right" and in control .... or helping the team to get the job done.

I do make distinction from control and direction, though well functioning teams given a challenge when allowed to will typically self organise and become directive.

Context

Given I'm talking about work, it is a professional environment, there is money changing hands for effort & time, it's not social or family, or personal relationship.

Therefore there is a defined environment, be that an expectation of work or hours spent in a location. Now all good management (or rather team facilitation) is flexible, but to a point.

Allowing someone to be absent for weeks (or even days) and not taking action but to wait and stew until their return and explode is about as far from a constructive or well functioning choice as you can get.

The key here is professional environment. I am not condoning Prima donna behaviour or "the end justifies the means" excuses, though I am advocating that there is mutual respect and acceptance of responsibility, on both sides.

If some one doesn't turn up for work for days in a row, sure you check in on them find out what is going on (it could be an emergency). But you don't simmer in the office "tolerating" their behaviour because they are a technical genius and then explode when they return, you deal with it. It's contractual if nothing else.

Personal

There are two sides to the personal aspect that strike me.

First, is that most of these issues come from ego, of any team member. It could be "da management" or members of the project team. Personally I don't differentiate or accept that any team issues, are only "the workers fault", there is a shocking amount of managers with challenging behaviours, just as there are workers.

So there can be ego on both sides. Management by responsibility of position are there to be aware of, and mediate this, opposed to taking it personally and attempting to "control" the staff.

Specific behaviours of anger, passive aggressive, negative etc, don't particularly bother me as they are just the symptoms of something else. It's just that individuals behaviour to a given situation. There are whole sites about how to deal with individual behaviours, google will help with that.

Find out what is behind the behaviour, and if it is relevant to the project, or if it's personal to them ........... which brings me on to....

Point two: being that we all have our own personal issues, and the vast majority of the time, for the vast majority of people (in my experience) separate that from work. And to a degree that's good, it's professional.

By way of example, the original poster advocates blaming an employee for experiencing an addiction and firing them. Luckily as someone pointed out, in many places that is illegal. Let alone immoral to me.

Some times we are overwhelmed by the situations in our lives, be that burnout a personal crisis, life in general, etc.

How a company supports it's people is very telling of how it's people are going to support the company I've found. My experiences are more of Europe than North America, though I've seen provisions for HR and employee support on both sides of the water.

I don't personally want to run a company and turn it into a counselling help session all day long, though I do accept there are responsibilities and healthy ways of supporting people. Respect at work is a two way street.

Shouting at people or threatening them for not working weekends consistently, and then firing them the first day of holiday they take is no way to do business.

So my advice is to lay off the condescending approaches of :

how do we control them

how to deal with people who don't do what you say

Nerds are X, and this is how you manipulate them

etc

And try and look at the bigger picture, and most importantly yourself before trying to blame, control, understand others.

Friday, December 17, 2010

One of my ongoing pet peeves it's the marketing over substance of the usual "agile" and "scrum" proponents.

I've found near constantly that the focus of this approach by it's advocates, is not to facilitate a team; but to prove that the process (i.e. scrum based agile) is the best (and typically only) way to run a technical project, and write software.

Agile? ......... sounds more ridged to me.

I find this ironic as the pushers (appear, in my experience to) rarely come come from a software architecture, or at least development back ground. It more appears a thinly veiled covering over typical old school management tactics.

Ignoring the apparent "I'm right your wrong" title (which sums up what I'm talking about) and going straight for some of the contents of the post, that supports my points.

(Points they are ironically trying to distance themselves from, reading Arnold Mindell would help so many .....).

"Will Jessup notes that developers tend to be highly intelligent people and often won’t just do something because we say so. He suggests a dialogue."

A dialogue ? You mean actually communicate with a team, share a vision and try and focus on a desired outcome opposed to just telling people what to do ? ......... now there is a strange approach that will never catch on ......... sheesh, is there that much ego about still ?

I'll ignore the "developers tend to be highly intelligent people" as anyone can see that for how it's meant.

There is really little surprise there is resistance to the technique when this approach in used.

"Kevin Shine suggests that we should move from selling to getting them to buy in of their own accord: “There is a big mind shift between these 2 thinking approaches. One is collaborative and cooperative and the other is more command and control."

The obvious issue here is that the very common C&C driven approach is much more accepted and the norm, as well as being from the middle ages. The premise of "us and them" is set up by the method even before the person has met the "software team".

The situation is walked into with the mind set :

"I'm going to have to tell them how to do it and what is right. If they resist it's because I've not talked enough and told them what to do. Developers are difficult, I really need to dominate to prove myself."

opposed to :

"I'm here to facilitate an outcome, that of a cohesive efficient directed team. The team will deliver a finished product. I'm not actually building it or solving the logic, though I do have a role to support the team how ever I can, and interface with the business. My role here is to understand the context of the work within time lines and communicate that to both areas. This is we, not us and them"

If the focus was an outcome opposed to being right, the focus would be on humble facilitation and progress, not proving process. One of the biggest failings of the application agile (not the method itself) being the tenant that it's pushed as:

"Agile right - developers and experience wrong".

It's top down hierarchy, "Developers are stupid and argumentative, treat them as such", again no surprise there is resistance.

But the focus of dealing with that resistance is always the developers? ......... how about the cause of it, the manner in which the change is being applied, and by whom ........ an applier of agile who is complaining about resistance maybe .......

That is seems some kind of revelation that team work should be collaborative or cooperative to the usual pushers of this technique speaks volumes.

This has nothing to do with agile or scrum. The title of that piece should of been : "Why being difficult, condescending and telling people what to do without engaging them will cause difficulties".

An example :

"In addition he points out that a new Scrum Master needs time to gain the respect and trust of the team members."

Isn't this kind of thing blindingly obvious? Sure I might of trained as a counsellor to help me understand group work, communication and respect. Let alone how to be client focused (which I switch to the "client" being the project at work) to help me take ego out of it.

But given that these kinds of points are being talked about as if they are new or some kind of magic approach, is very disheartening and explains a lot as to the failure of enforcers of scrum & agile.

Lacking a clear and compelling and a sense of urgency the team doesn’t commit. Ashish goes onto suggest 1-1 coaching, root cause analysis and rigorous use of retrospectives to help team members discover issues on their own.

You don't need urgency, though I sense that is just code for "panic and rush everything".

What you do need is an understanding of timing in a business context.

The 2nd point that isn't talked about from this quote, is that the assumption is that it's always the developers or "other team members" that have the issues. Wholly arrogant in my view. It's just as common that it's the people trying to enforce agile/scrum or management themselves who have issues, just as we all do, it's called being human.

---------

Overwhelmed by ego and the need for the method be be right, makes most view anything that challenges them as something that is "wrong" or "difficult".

Opposed to seeing the method as a way of facilitating a better outcome for all. How long are we going to have to endure this kind of thing being top down and prescribed?

Little wonder a lot of successful software houses now are small developer lead teams. Any why ? Because it's fluid, communication is done when necessary, and the subject experts are allowed to engage opposed to being manipulated. Let alone the lack of interruptions .......

Leadership it's about communication and facilitation, process is just a way of managing that.

Resistance is a good thing, it means there is passion and thought, there is a reason and likely something that hasn't been considered. You investigate it, you don't try to bully or scare it away, as some would seem to advise.

I think a lot of this is tied into typical business people's lack of ability to listen, either to a team to hear what is actually going on, or more importantly themselves to detect the real root cause of the resistance ....... ego.