It's a real grind, what we do here

In real life, software delivery rarely is a piece of cake - writing actual, production code doesn't resemble "happy path" tutorials, industrial domain models are much more complex than "Animal -> Dog" hierarchy, effective automated testing gets twice as hard with every new dependency discovered, etc.

It's not a "simply follow the instructions" type of work.

In fact, to do their daily work, software delivery teams have to constantly deal with numerous (& various) issues & problems, fight impediments, tame unruly technology that sometimes seems indistinguishable from magic ;) And to do it efficiently & smartly they have to keep drawing (& applying) conclusions from past experience to continuously improve.

It's the way in which we deal with these obstacles (quickly & relentlessly or crawling inch by inch) that defines our overall ability to deliver (famous topic of 10x developers has its origin here ...). I'm quite sure I don't have to convince you that it doesn't depend just on our skills, knowledge & experience, but also (most of all) motivation, energy, perseverance.

Lack of any of these three may cause two types of effect:

• in case of issue - it may block us / bog us down for some time (reducing our velocity)
• in case of space for improvement - it may mean the wasted opportunity to increase efficiency

On the team level, the relative scale of effect can be limited: e.g. sometimes it's just a matter of getting 1%-2% improvement (barely noticeable), BUT it could add up to the overall result ("many a little makes a mickle"). Still, to get these 1%-2%, team has to apply effort & that requires (as mentioned above) a healthy dose of motivation, energy, perseverance.

Small leaks, big leaks

What if this team exists in the reality, where its causative power is limited by the severe, external limitation (its removal is beyond their capabilities), e.g.:

• modern, best-in-class, available tools are not allowed due to procedural reasons
• team doesn't have a straightforward access to information (/people/resources) it needs for their normal work (so they have to explicitly request it each time & wait & wait & wait ... etc.)
• there are synchronous, manual process steps performed by content-free people who do checklist-style governance
• team is required to provide excessive paperwork that no-one will ever read & that will get insta-outdated
• etc.

Well, there are always some limitations (that's the way world is built), but keep in mind that these we're speaking above are of so-called enterprisey nature (caused by policies, organisational inertia, etc.). So in other words - it's quite clear and obvious for the team that these constraints:

1. do not add value / prevent any damage
2. should not be applied in this particular case (either because they are badly designed or not fit for this particular purpose)
3. are outdated & don't reflect the changes in modern day reality

Riding with a handbrake on

In team's perspective, the situation is as follows:

Organization (/management/executives/bosses/whoever) encumbers them with some nonsense that easily "taxes" them for NN% (two digit percentage) of their efficiency, but still asks (requires?) them to work their assess off to get all these tiny 1%-2% improvements in endless, daily battles.

Figuratively speaking - ship is burdened with a huge anchor slowing it down, but instead of cutting it off, all the sailors are given teaspoons & expected to row harder. Does it feel fair? Does it motivate anyone? Does it sound like something an intelligent, smart person would commit him/her-self to do? Yea, exactly.

Let's put the things straight - in many cases people get demotivated & discouraged NOT because tasks are too challenging, they don't care or they can't be arsed to put effort into them. Pragmatic, practical people simply have this positive "laziness" that makes them resist stupid kind of activities that should have been fixed first.

Pic: © studiostoks - Fotolia.com