登录查看更多内容

The Problem with Agile is Clients

App Developer Studio

Official FlutterFlow & Shopify Experts. We design, build & launch beautiful, award-winning apps, bots and AI solutions.

发布日期: 2022年6月15日

+ 关注

Perhaps a better title is “The Problems Clients have with Agile”. But that’s less catchy.

We’ve used Agile for many years. Full disclosure: we’ve been saying we use Agile for many years but we’ve only been using it properly for a year. Like many others, we assumed we were doing it right when we had daily standups and liberally used the word Sprint. Then the penny dropped - it is actually really just about how to be focused and getting to working software quickly. So we are now borderline neurotic about the whole scrumban bang-shoot because, well, it works.

But often it doesn’t work so well for that most curious of creatures - our clients. We’re finding a few recurring problems and I’m interested if others share them and if they have suggestions. We’ve developed our own which takes the best of Agile but mitigates the below which I’m happy to share another time.

Why Clients and Agile don’t get along:

Clients don’t deeply understand Agile, why it is used and what may happen during a project. It’s just not how most people and traditional companies think projects are run. MS Projects owes us all an apology. So, when you’re 2 months in to the project and discover a problem in the current sprint that wasn’t foreseen (or even considered earlier), they’re not very sympathetic. They think everything should have been analysed up front to allow for smooth sailing. Blockers are seen as failures rather than inevitable hiccups.
Clients want fixed cost and time estimates up front. This isn’t really their fault. Like any business, they must evaluate developers like any suppliers - based on how much they cost, and how long it will take. Persuading them that we’re nice guys working in high-performing, self-manaing teams, and they should indefinitely pay us to constantly respond to their changing requirements based on validated insights is a tough sell to their Procurement Department.
Mismatched objectives We do actually want to please our clients and for them to succeed. Not least so they can keep paying our growing invoices. But, let’s be honest here, in the short term: clients want the most they can possibly get for their dollars; agencies want to get the most dollars for their input costs i.e. developer hours; and developers want to hangout on Discord (not really but you get the point). The Agile promised land of self-managing teams pulling together like battalion of shock workers is really an aspiration. We’re just trying to get as close as possible to it for as much of the time as possible. Over time - with trust, a stable team, pride and good management - Agile bliss becomes more attainable.
The toughest bits are kicked down the field. This shouldn’t happen. With a lean, Agile project the team should start with the most valuable features. But there’s a big and very real temptation to start with the quick wins and impress at the early demos. The most complex and highest-risk elements (which are often third party integrations or unusual hardware interactions) are left until the end along with the hard learning that it can’t work as envisaged. By then it’s like asking for directions and being told “well I wouldn’t have started here”.
Imperfect knowledge. Steve Jobs used to scream at people if the circuit boards inside his Macs (that no customer would ever see) didn’t look physically beautiful. But he was a freak (and a genius to boot). Many developers are fine with ugly but functional code. They use the stack they’re familiar with. They don’t update libraries. This is reality and it is also understandable - we all prefer the devil we know, are nervous to take risks and are under time pressure. Code review is an expensive luxury. The client doesn’t, for now, know any better other than perhaps some buggy or laggy performance. Difficulties around maintenance? Maneana.?