When did Agile become an excuse to deliver a terrible product?

Maybe this has a lot to do with my own experience of Agile or people believing we were being agile. I think in my case we were doing wagile or agile fall. We were doing sprints, retrospectives, whole team involved in writing requirements but a lot of things were de-prioritized until some date in the future when things would be done.

Often when the team highlighted issues with a story in it’s current format or planned implementation we were told something along the lines of “Do what’s there, we’ll be ripping it up and starting again in the near future but get it out the door now”. This was seen as an agile approach by our management.

I’m wondering has anyone else experienced delivering a crap product because “we’ll be ripping it up later” being fobbed off as being agile?

How do we help people see that this isn’t OK?

3 Likes

Ah, the sins committed in the name of agility :smiley:
Tech debt is a disease and since XP agilists have been fighting it, but the message has been lost somewhere.

An agile/lean approach would suggest:

  1. Build the minimum amount of features that resolve the customer problem
  2. The features that you build need to be high quality so that maintaining them and changing them will be easy

What the world generally understands is:

  1. Build all sort of shite and don’t care about quality, fast fasteeeeerrrrrr!
7 Likes

I think it depends a lot on the company, the domain, the culture and the kinds of developers you have. The more developers that are hiding behind some “curtain” of shit code, the more often you see things like this… or see them use bad standards of practice to justify why they are writing shitty code now that they are never going to go back to. It’s really hard to test code. It’s really hard to maintain a high level of tested code when you are pressured to have something out tomorrow. When testing isn’t baked in from top to bottom… then you get these, “do it now, and we’ll pay the piper later…” agile practices, which aren’t agile at all.

The best way to counter this is to start making testing visible and a service to the company. Any company that takes the testing practice seriously, has a lot of measures in place to ensure reliable, mostly good code goes out to production. I’m not talking about the Amazon/Facebook types, that’s a whole other story and there are a lot of factors I’m glossing over too, but in general, companies that want to maintain clients, maintain their leadership in the industry/domain they are in, especially if there are competitors, will look for faster feedback loops and higher quality from everybody, not just devs or testers… and that’s where agile really shines. That’s what you have to strive for and sometimes it happens and other times, it doesn’t. It can take years for a company to get to this point. You, as an individual, may never see it before you move onto another job. That’s the bummer.

3 Likes

In my experience this feeling that “we are delivering a crappy product” has always been rooted in communication issues.

in 70% of cases it was the technical leads and senior members on the team that failed to articulate why is the quality important to the business. “Crappy product” does not mean much if you talk to a high level management, they just stop listening to you, they have got important stuff to do. “We are loosing 7 man days every month, but if we invest 30 man days today we can decrease that number to 3 man days a month” is what they listen to and respond.

In 30% of the cases (this happened on super-highly agile teams, XP, etc.), it was the business failing to communicate how important the deadlines are and what happens if we miss them (millions of £ in fines if we slip by a day). The business was fine with reducing the quality for the next 6-12 months and producing technical debt to hit the deadlines with core features and recover from errors by doing production support. But the devs and testers used to “goldplating” were fighting for more and more quality, even though it was the wrong choice in those particular situations.

Its not a technical problem, its a people’s problem. My advice is to talk more with people and build a trust culture. Also, try to prove to firstly yourself that having a “crap product” in the situation you are in is actually a real issue by thinking in business terms not techie terms.

I also recommend reading about the theory of constraints in management, it will help to see yourself as a part of the whole organisation and how decisions are made that help the whole business, not just IT (a good decision in IT might be a bad choice for the business, etc.).

P.S.
By “This was seen as an agile approach.” I assumeed you meant “This was seen as an agile approach by the majority of the team including BAs and DEVs”.

4 Likes

Apologies I have updated the post. “This was seen as an agile approach” was management. The team felt that if we were going to be ripping something up within the next 1-2 sprints then we shouldn’t be spending time on it in the current sprint.

We felt it should be thought about better rather than potentially spending 3 times the development work on it. Improving on something is reasonable, however ripping it up so soon and knowing that you would be and what you were going to do in the next sprint to rip it up but not communicating it to the development team seems ridiculous. By rip it up I really do mean rip it up by the way. Entire UIs deleted, user flows drastically changed etc.

To add a bit more context to the situation: we weren’t actually releasing the product to customers at the end of each sprint. We had an MVP release date to reach before it would be considered to be released to customers. Even when this MVP was achieved it wasn’t a product that would provide value to our customers. They had highlighted what they needed working before they would consider spending money on it.

I have seen that as well. Some teams interpret Agile as “less or lack of design”, which works sometimes and sometiems does not.

Still, sounds like a lack of communication. I see where the testers and devs are comming from now more or less in this story. I still don’t know what the management thought and their reasoning process. What did they make of the process? Did you tell the management the story you have just shared here? I am pretty sure they would have something valuable to add to the conversation. You could start by asking the them “we feel like we are wasting time developing and testing something and ripping it up in the next sprint, can we explore alternative ways together with you to reduce the waste in our software design and delivery process?” If they resist the conversation you could test their integrity (they love Agile?) and try selling them by quoting the agile manifesto “Business people and developers must work together daily throughout the project.” which could be interpreted in here as “facilitate better communication in the project”. You could also quote “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” and invite them to your retrospective.

This is hard to do if there is no trust culture in the company, you need to feel safe to have this type of conversation.

Updated context: I finished in that company last week :laughing:

We did explain many times from business, effort, number of meetings side how this approach made no sense but it was an us Vs them culture. We were essentially told “do this because I said so”. I agree you have to assess the safe space to say it in. Unfortunately for us that didn’t happen and many of us have left but the company says “we are agile”.

Thank you for your advice I hope it will be useful to many others who find themselves in the same situation as I was in.

1 Like

@heather_reid “us Vs them culture” very common, actually extremely common.
Would you be surprised if i told you that there is one specific principle in the agile manifesto that says “Business people and developers must work together daily throughout the project.”

Don’t take my word on it
http://agilemanifesto.org/principles.html

2 Likes

Shameful plug: A good coach can help :joy:

2 Likes

Been there. This is sadly common and yes, there’s a lot of underlying communication/power issues in every place I’ve seen it happen. Some of the common factors I’ve run into are:

  • Management committing to unrealistic delivery dates - which may be due to customer insistence or it can be a completely unilateral decision (I’ve seen both).
  • Sales team sells something to a major customer that doesn’t exist and promises a due date that’s not realistic (Also a communication issue - in the form of management incentives not being correctly aligned)
  • Micromanagement (usually a control issue: managers not able to trust their people to work independently and make their own decisions. The reasons behind micromanagement vary - I’ve seen everything from legitimate OCD to thinking of everyone else as mere widgets who should do what the manager requires no matter what.
  • Misunderstanding agile - Way too common: someone gets the notion that they can “go agile” and miracles will happen - but they forget that without a lot of work and some serious interruptions to productivity, all they’re going to get is somewhere between an unholy agile-waterfall hybrid and utter chaos.
  • Forgetting the big picture - Another common problem I’ve seen, where the overall design architecture and at times the overarching purpose of the software gets forgotten in the relentless drive to sprint on this and that and deliver this and that. Without considering where this and that actually fit in the organization and software, you end up with at best sub-optimal implementation.

So, er… yeah. I know the situation all too well. If management is the source of the problem, I doubt it will be fixed. It’s way too easy for upper management types to presume that the constant issues in their domains are the fault of everyone except themselves.

3 Likes

We think that process fixes thing. It doesn’t. Thinking empowered people fix things. Agile is great insofar as it enables empowerment to do the right thing, but when it gets turned in a way to ‘manage’ people through process, it ends up hurting things. There is no easy fix for hard problems (and any problem worth solving is hard) and I think that Agile has far too often been sold as an easy fix. When we think we have fixed something we stop looking for ways to improve and end up in all kinds of bad places :slight_smile:

2 Likes

There are a couple of problems here.

First off, a software development methodology is not a silver bullet. Just because you’re agile, it won’t stop people making silly decisions. Inexperience, lack of communication, poor management - these will bite you in the ass no matter how you do it. You sound like you’re blaming agile - I wouldn’t. From your description, I’d blame them for poor planning.

Personally, I feel agile helps prepare you for changing requirements, but what it will never do is make change painless. You can’t just suddenly change your taxi sharing app into a database. Your management should recognise this pain.

From my own recent experience, we’ve delivered an MVP for our a client under very stressful deadlines, we’ve burned ourselves out a bit and made a lot of awful hacks, to deliver it in the short term. However, currently I (and other consultants) are giving very strong advice to not continue pushing like this. Give us some time to redesign the MVP, fix the issues, and not work under strong pressure. I dislike arbitrary deadlines because they encourage short term thinking. The worst part is - there’s often no need for the deadline.

Secondly - agile methodologies are actually really bad at long term planning. Scrum, Kanban etc provide no framework for the long term. Lots of teams assume that this is because you don’t need to. You do. There’s nothing wrong with sketching out long term plans, roadmaps, and trying to plan for the future. Trying to think about making your product scalable, secure - you might not have to do it right away (and sometimes you just have to get something to show the investors!), but you should at least try to spot problems on the horizon.

3 Likes