A brief discussion in which developers invent development; ‘agile methodology’ becomes something to sell and buy, and how this trickles down into an organisation’s culture; the 2019 value of agile, and how that manifests as concerns over Post-it Note colour; how honesty might save us from ourselves.
‘Illusionist Software Developers’ are developers who actively conceal how they spent their previous day when discussing details at the daily stand-up. They will embellish, adjust timeframes, and invent problems they miraculously solved. This effort is to avoid the statement “I didn’t get much done”. A lack of communication is obviously a bad thing, misinformation is worse.
From this, however, we cannot determine if they are ‘good’ or ‘bad’ developers, more that they exist in a culture that does not appreciate honesty. The stand-up becomes a reflection for the company culture at large.
A commonly heard opinion (if you actually listen to developers and not just infallible blogpost authors) is that stand-ups force developers to undergo performance reviews on a daily basis. This idea should be inaccurate in healthy organisations. The whole point is to inform and share ideas with the local team, everyone can have a suggestion of what people are up to and help out. The performance review aspect is a side-effect of unhealthy cultures, where there exists a power imbalance (or the feeling of one) between participants. Those developer delimited burn-downs may used against you, the remedy is to over-estimate tickets rather than admit failure. As Intel’s Andrew Grove put it: “Only the paranoid survive”.
With the prevalence of Slack and JIRA, it’s debatable if the core purpose of a stand-up is even necessary as people continually inform each other of their activities (ignoring signal to noise ratio). Stand-ups at least force people who are less comfortable communicating to feedback, which I understand is useful in the practical world, but feels like a reductive extension of the ‘developers cannot communicate’ argument, grounded in dated stereotypes. Stream of consciousness into Slack is my preferred method (at the chagrin of my coworkers).
Be deeply suspicious of an organisation where developers seem to have bountiful days five times a week. Whether we like to admit it, a lot of software development is starting at docs and wondering why a library doesn’t do what it is supposed to. Admitting we don’t know all the answers can be greatly freeing, however it’s likely to mean the ‘good developer’ stereotype no longer fits. Weigh up your options.
Off-days exist, as do days where you’re under-the-weather, as do days where you couldn’t care less about your job. No-one is whiter-than-white, a healthy organisation realises it’s made up of actual people.
The ‘people over process’ tenant of agile software development has been difficult for a lot of organisations to stomach. It is difficult to package and resell. An industry grows up around this idea misinterpreted. Executives pay consultants huge sums to introduce agile practices to their organisations (when they learn GAFA might have done something like it): they get a training course on Scrum, all the extroverts are made POs, and you should stop what you’re doing and work on this exec’s pet feature because you’re agile. ‘Working software over documentation’ is a tricky one also, especially for enterprises with a view to scale. This problem arises particularly around those features which take longer to document than they do to code, also communication between teams (consumer driven contracts are favoured here, or a protocol based in schemas). Developers lacking initiative will often jump on missing documentation as a reason they are ‘completely blocked’.
Through the commoditisation of agile, the human message is removed. This leaves us with Frankenstein versions of the original intention, where developers are actively trying to avoid communication. This happens because as the new framework is implemented every ounce of productivity is eked out, self-respect begins to ebb. Are the best engineers those that never appear to drag their feet? Illusionists abound.
Breeding honesty in an organisation is complicated: giving feedback well is so difficult that most would prefer not to do it (and instead choose gossip), while receiving feedback is judged with suspicion, especially to a more ‘senior’ person (vertical relationships should be rejected wherever possible). Here, I favour something along the lines of Ray Dalio’s radical honesty: accept that it’s never easy to give or receive feedback and do it because it’s necessary.
Agile software development is a technique that encourages communication and simplicity over strict rules and guidelines. The manifesto website is four bullet-points long, which seems almost ridiculous when you consider the huge industry that’s blown up around it. Scrum is a packaged version of some of these ideas, which makes it easy to convey to people. The problem here is that each organisation is unique: Amazon’s method of managing priorities is probably greatly different to what is needed at your organisation.
As a reaction to 20th century software development techniques, agile was hugely important and changed everything, old methods where outed as ridiculous and cumbersome. Yet somehow we’re in 2019 and allegedly adult people raise concerns about not following a Post-it colour coding process, 5 year backlogs are presented to bemused start-ups employees, and 23 year old ‘senior consultants’ educate on Scrum.
Agile may as well be reduced: “Talk to people and write good software”, I’m calling this iteration ‘Agiler’, I hope it catches on.
Another, more realistic, option is a return to less dogmatic, more honest methods of communication for building software, that the original manifesto seemed to be about. Attempt to eschew toxic pre-packaged agile that puts up barriers between real human communication. The stand-up’s response to “I wasn’t feeling it yesterday” will tell you a lot about an organisation.