A slightly strange title, but let me explain. First of all – it’s possibly self evident, but for those who don’t see it – developers in so many industries are treated similar to mushrooms – keep them sustained in a dark room and they will produce useful material. On the other hand – we have marketers / designers / project managers. The former two of which are (and rightly so in many instances) considered to be the driving forces in their field and thus are exposed to the sun (the clients / world) by virtue of glass walls & ceilings.
I have for many many years been both a developer and a social person. I enjoy interacting with clients / fellow developers & others – be them from media agencies or ‘end’ clients (ie: Sitecore Customers) and I have found distinct differences between the way different organisations interact with their own developers and (from a personal point of view) what I consider to be a disparity in how productive the developers can be directly linked to how close they are to the problem.
In this post I will explore why developers (mushrooms) should be allowed out to see the wider picture (greenhouse) more regularly.
I guess a large amount of this hinges on commercial aspects. Developers tend to be as a rule – helpful by nature, but not necessarily as commercially aware as some other members of a team. There is therefore, a simple (and obvious) deluge created between the desire of a developer to make great solutions (I don’t really think of it as just software) for our clients, and the need to keep in budget and to timescale.
Not many of us set out to make something a client doesn’t want, in fact – the largest satisfaction I have gained in my career has been from enjoying visible and/or measurable customer satisfaction from the users – be them content editors (think simple stuff like the Right Click Publish article I wrote a while ago). It’s trivial stuff to most of us – but it can be insanely useful to the folk that have to do this 50 times a day. However, there is also I feel a huge communication breakdown for developers sometimes in figuring the stuff that management want vs the stuff that would make life easier in the trenches.
Shadow development has often been a term used by folk I have met in the industry meaning a way of sneaking developments into a project that were not *technically* completely necessary, but made life easier for developers or a.n.other individual. They are often developments that take place in ‘fat’ time that developers thought they *might* need in order to complete a task, and is often the section of time in a project that *really* makes a difference not to deliverable functionality. I think in many respects they are a hangover from waterfall methodologies – but in truth – the majority of organisations cannot cope with a true agile environment, so many such hangovers exist (how many times are your estimates in hours / days not points for example).
This practice is both completely in line with and simultaneously wholly against some of the agile principles. On one hand you have the ‘complete tasks in the simplest way possible’ on the other you have ‘why put off ’til tomorrow what can be done today. I am a firm believer that much of shadow development will be developer vanity (code doesn’t look right / not how they would have done it), some is genuine refactoring changes that are required for their task and maybe they choose to do it properly rather than quickly. There is a large amount of development that will go on though as a result of shadow communication (see below)
Either way – in some ways it’s a challenge that should be embraced in a more structured manner if the need is there – but recorded as a spike in the sprint for visibility.
I believe the reason that the above even exists is often a symptom of lack of communication routes laterally within an organisation. It will often be Jim / Joan in dev talking to Rachel / Claude in admin / content on an unrelated topic ( think bug / demo / whatever) that will drive these discussions and show a solutions oriented developer how the system is used ‘in the real world’. I find work based alliances will be formed in these interactions which allow a developer to be FAR more effective than they could otherwise be.
So where am I going with this??
At its core – agile methodologies should allow flexibility and a constantly evolving system (which in reality in many organisations is no the case). Too many organisations ‘do’ agile rather than ‘are’ (see – The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso – and have your manager read it too). This communication within a team can be invaluable and should be, in my opinion, encouraged, as with a solutions oriented developer can really provide a way to ACTIVELY feed in to your agile process. Small, measurable, iterative changes are a key focus of an agile team, and this should most certainly include input from the developers too. Without this lateral communication layer, it is highly unlikely that the 10 minute change that could be made by a developer which could save 10 minutes every day per content editor would ever be found. That change could easily be factored into a future sprint.
Another point to note on this is that this internal team communication ideal is just as applicable inter-team. I have been in far too many positions where the developers are isolated from the client. I ran multiple extremely successful projects where communication with the client directly has ultimately found solutions that have better suited the client than if it had simply been words on a screen in Jira / whatever.
But – they are bugging the crap outta me ….
I have talked a lot here on why I think its important for non-meeting communication to take place within a team or between teams. I am not an advocate of having every dev in a medium / large team have direct communication with the managing director. I would rather suggest that the project has key individuals who is assigned and therefore builds personal relationships with the people in the trenches who will use the software day to day.
I would say that the above tends to mean that projects where they have in house resource / have hired in contractors will more often result in a closer product to what a client truly wants that an outsourced project (not always I might add – it also depends a lot on the quality of the developers and other staff). This is often because the in house staff can wander across to the desk of or are allowed communication with those who are really using the system day to day. They therefore can suggest solutions based upon what they see.