Multidirectional s**t umbrellas
The proverbial shit umbrella is explained described as protecting the team from the forces in management above the team. What about the other direction?
This is a vastly unfair diagram. I just wanted to emphasise the weight of decisions from the top outweighs the bottom
Umbrellas
I understand the need for teh umbrella, as they can cause responding to minute on-the-fly features that have for some reason become the highest priority. Or the umbrella can dilute especially harsh feedback to something that can be brought to the team as constructive feedback.
There is another aspect that I think goes undiscussed, does the shit umbrella also protect management from the development team. As that person often has to act as a messenger to both sides, they often have to filter out problems the development team has with management. From my own experience on teams, I have been in multiple months where “business relationship” was brought up in the retrospective because it was one of the worst aspects of the team.
As the book ‘The innovators dilemma’ discusses often it is not the execs making the decisions or even the low-level people making the decisions. It’s the middle management. This is because the middle management has the option of omission and they are unlikely to share ideas to make them appear in a bad light.
The book argues that this middle layer can sanitize some of the true innovation from the level below if it looks like it doesn’t fit into the current strategy. In the book it talks from the perspective of a groundbreaking piece of technology that isn’t capitalized upon as it doesn’t make the current hard disk technology better.
Team influence
From my experience development teams in business often want to improve, good developers often don’t like work with sub-optimal tooling and processes. I know personally that I find it rather boring working as a code monkey, walking into work on a Monday and being given a ticket and the solution and told to go and write it.
A classic example is teams adopting an agile methodology whilst the rest of the business doesn’t this leads to a pseudo-agile effect where everyone pretends that we are working in an agile way but that is not truly the case.
Bad news
I understand that nobody wants to be the bearer of bad news, this is especially case because us humans are attribute the problem the bearer (there is a whole lot of psychology around this problem).
This means however that we are susceptible to the innovator’s dilemma on a whole new axis rather than delivering a new type of product, it is how we deliver that product. We keep ourselves trying to get marginal gains on technology that has a limited lifespan.
The problem is with that if our competitors can drastically improve their focus, with better product focus teams their product is likely to become a lot more user friendly. This user friendliness will eventually hurt your bottom lines.
As a “developer” I would like to “influence the wider business”, “to promote true agile thinking”
I have to admit this post comes from the point of a developer; often many conversations get resolved with some outside force wanting a specific action. For example, as a team if we wanted to try a new way of working that would affect the way we would report to stakeholders it can cause a sticking point. For example, if we wanted to try #NoEstimates it would be difficult if the stakeholders still wanted estimates (that could be abstracted but I digress).
A few times I have found that that just reaching out to someone directly can clear up so many communication issues that can crop up. However, as a move this needs to be done with the up-most care as you go up the food chain those people often have bigger fish to fry than yours.
Outside of doing the legwork yourself, maybe you need to work on allowing some news flow through the umbrella from below. This requires you getting the umbrella onboard, and willing to slowly push for the new method of seeing work over a period of time. This may be a hard sell.