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?
Ah, the sins committed in the name of agility
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:
Build the minimum amount of features that resolve the customer problem
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:
Build all sort of shite and donāt care about quality, fast fasteeeeerrrrrr!
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.
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ā.
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
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.
@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.ā
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.
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
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.
