I don’t mean they outwardly proclaim they don’t want to be agile, no one would be foolish enough to do that. Who doesn’t want better software, faster anyhow?
What I mean is that observed shop floor behaviour will override the ideal or espoused agile ways of working, time and time again.
“How long until the first version is complete? Marketing needs to confirm a firm date for the campaign”
“Here are the high-fidelity pixel-perfect designs for web and mobile user journeys for the development team to implement”
“We will have to let another of our local teams go because we get a more cost-effective solution from our offshore IT supplier”
“The product owner does not speak to the engineers directly or attend the ceremonies, except for demos, because he is too busy managing the product”
The agile coach may shake their head, throw up their hands and say they ‘can’t help a client who won’t help themselves’. However, that response would be ignorant of the pressures of business and the complexity of large organisations.
Winning business, developing products, responding to industry demands, keeping up with competitors, technology obsolescence, regulatory requirements, managing staff and suppliers, cost control, maintaining quality, and satisfying shareholders. Distributed across different counties and regions, headed up by various directors and managers.
The notion of small, autonomous, cross-functional product teams who ship frequently and practice continuous improvement can seem like a pipe dream, particularly if the organisation is not in the business of technology.
Unless the CEO spearheaded Scrum or agile ways of working, it often remains just one small initiative in the product or technology department. Restricted by structural constraints and organisational limitations. Ready to be overridden, deprioritised or ignored when something more important comes along.
This is the reality of building enterprise software. No one has failed or should be disappointed when agile teams fall short of the espoused ideals; there’s already enough pressure.
If you are unhappy with your development team, they may need more detailed guidance.
Clear and effective software requirements can help with this.