TL;DR Software development units are not really as simple (and linear) as the conveyor belts, so they should not be treated as such. But when in pit of despair, starting with some simple structure (that can be at last partially - in the most simple "areas" - governed automatically) may be a reasonable way to approach serious systemic problems. Tools (like JIRA) SHOULD NOT be running your team(s), but can provide them some kind of stable work framework to build some ritualization upon. It doesn't work beyond some level of sophistication, but it may be exactly the spur people need to take it from there.

Recently, I've went through some of my notes on org culture & even more specifically, on so-called "engineering culture" (one of the favourite topics of mine). One of the entries (in fact - a tweet) has caught my attention, as it matched some of my recent reflections:

It's hard not to agree with Mathias.

Tools are not supposed to run your team, they should only help in aspects where "machines" are better than humans (automation of repetitive tasks, validation of error-prone activities, etc.). Extensive dependency on tools can (among others):

  • make critical knowledge disappear
  • stop people from thinking independently & instead - make them approve the reality unquestioningly
  • reduce the agility of change (adjusting anything requires a change in tool, it's another group of people, ...)
  • shift communication paths from direct ones to collaboration via tool(s)

There's nothing new here, I've personally covered that topics several times already. But there's more to the story ...

Judge Dredd for the hard times

Let's assume that there are significant systemic problems indeed. By significant, I truly mean FUBAR:

  • low awareness, low motivation, low ownership, low A2E (Ability-To-Execute)
  • far not enough agents of change or lack of mgmt support for change
  • too many dependencies, unclear responsibilities, communication chaos

Obviously one could say "just cleanse it with napalm", but ... yeah, let's put the shortcuts aside for a moment. How would you approach fixing situations like that?

Underlying (organic) work is absolutely critical (education, leading by example, small & gradual yet continuous improvements) BUT IMHO ritualism can also be very useful (ritualism = building up a habit by perpetual, extremely regular behavior). And here's where tools like JIRA can truly shine.

What I mean is an equivalent of Convention Testing (automatic verification whether agreed, non-functional conventions & standards are in place) in a CI loop, but for (delivery) processes & practices, instead of architecture & code.

Examples?

  1. Teams are struggling with DoD or some other daily routine? Workflow can "manipulate" them into being more attentive (in at least few, more or less obtrusive ways)
  2. Flow of work fails due to (lack of) communication, e.g. tester never know when & where their stuff is ready for the re-test? What if you add automated notifications to testers once CI confirms that artifacts based on particular revision have been deployed?
  3. No control over who works on what, why & in which order? Yea, I guess you've figured this out already.

Illusion or real fix?

My point is that sometimes, especially if people are too used to chaos, mess & overall helplessness, having the system force some boundaries upon them can help them build some rituals ... they'll start appreciating later (feeling good about the change). Of course it would be better to reach higher standards by enthusiastically implementing bottom-up ideas of self-organized teams, but ... you can either wait until it happens or help people by providing them the support & guidance of "the system" -> work environment around them.

But be warned - in some cases positive effects won't happen at all. If resistance is too high, people have the passive aggressive attitude or there are general, interpersonal issues that practically cross-out any kind of collaboration, digital gendarme won't help - people will always find a way to ignore it, walk it around or break it (e.g. by overflowing it with issues & causing a broken window effect).

Personally, I (by far) prefer simple, Kanban board-based tools that do not put many constraints over the flow of work (except of WIP ;>), but I've learned to appreciate smart usage of more sophisticated workflow-based tools for software delivery -> they can play a very similar role (& be as useful) as build system, deployment agents, CI servers & all other elements of development architecture.

They are perceived that bad by developers community usually as the general understanding of their role & usefulness is low -> these are the only tools engineers don't have direct the control over (they let it slip off themselves usually): hence their setup quickly gets twisted, complex (& detached from reality) because it's being covered by theoretists or people with limited understanding of delivery processes, who additionally do not understand that fine-tuning the workflows is supposed to be a continuous, feedback-based effort.

Share this post