1. 27
  1.  

  2. 13

    I believe nobody told management about the cost of Agile: Management gives up control of the scope. It is the developers who decide how much they will do until the next deadline. If management refuses to give this up, then Agile becomes a farce.

    In the words of the manifesto, what management does when it rejects the committed scope of a sprint is contract negotation instead of customer collaboration. The contract in Scrum is: Stakeholders (including management) decide stories and their priority (usually indirectly through a product owner) but the team decides how much they commit to for a sprint.

    1. 3

      This, and lack of usable management reporting, are the two things that kill agile (particularly scrum) in most organisations. I think a lot of the thinking behing scum is actually useful if you can put it into practice, but on the ground that’s quite rare. Instead you end up with a bunch of ceremonies and no improvement in scope management, estimation or quality.

      1. 1

        This is definitely true, but also a potentially misframing of the problem. They don’t have control of scope anyway without excessive burn out and ever-increasing standard deviations of velocity.

      2. 10

        I strongly disagree with the entire section deriding technical debt.

        One of the best things you can do for yourself as a software developer is running your own business. I don’t mean a consultancy business where you’re essentially an employee that sends invoices every month. I mean something more like a product business.

        When you’re building a business, you don’t know what features are going to bring money in. It is so well-known that we all don’t know what we’re doing that the startup in-joke is to put “pivot” explicitly somewhere on the roadmap. I will by no means defend Agile as I think that’s nonsense too, but the aversion to technical debt is (I think) the most likely cause of this supposed “divide between business and programmers”.

        Who cares if the feature you implement is beautifully designed and backed by a comprehensive suite of automated tests, if that feature ends up not making any money and is scrapped anyway? Professional software development doesn’t happen in a vacuum; the code you write is an investment, and you and/or the business should expect to see a return on it. Technical debt is an excellent way to limit potential losses from investing in a feature/system which turns out to not be profitable.

        Debt is not a bad thing. Debt is what allows you to live in your house before you can actually pay for all of it.

        1. 2

          It doesn’t hurt to go back to the source when the “technical debt” metaphor is discussed: a lot of the “not all debt is bad” discussion is exactly what Ward said - http://wiki.c2.com/?WardExplainsDebtMetaphor. I have two points here

          1. Managed debt is not a bad thing, but you probably wouldn’t be able to get a mortgage on a house if you were already maxed out on your credit cards, and you can’t take on more debt when all your income is going on paying off your minimum payments

          2. sometimes the metaphor breaks down because whereas financial debt is fairly predictable (it’s x% of the principle, compounded) the cruft in your codebase may have unknowable effects on your development speed. Say for example you left an XSS attack in your frontend, it won’t slow you down at all adding future new features if nobody finds it - but as soon as they do, it might finish you off completely. The analogue here is not with debt, more with unhedged options, or with uninsured risks. You gave yourself an extra £500/year for pizza by not insuring your car against theft, but now you have no car and you can’t get to work.

          1. 1

            That is true. But it’s also true that not every stage of a company is searching for a business model. Companies stabilise and need to care about existing systems. And that include cleaning up technical debt. Of course, only of the parts that bring money…

            The problem I see with Agile practices as understood by many business is that they tend to be a “new features all the time, no need to clean up” way beyond the point that’s reasonable. Because having a solid system that can scale and decrease maintenance costs is less glamorous than the new initiative to tweak a awful mess once more “to have a quick win”. So it ends up taking way more that it should.

            Profesional cooks clean as they cook for best operation, but if they are in a big run, at least they clean after the fact and before making another dish…

            1. 1

              Although I agree, that’s where contracts and generative testing can help. The overhead on programmer’s end is low enough that code thrown away isn’t a big deal. Same for other automated analyses.

            2. 5

              I hate Agile, because nearly every team I’ve been on which used it skipped this part of the Agile Manifesto:

              That is, while there is value in the items on the right, we value the items on the left more.

              You’d never pack your car and drive to somewhere across the US without at least a general idea of where you’re going, but that’s how I see a lot of agile teams work, because we’re “Responding to change over following a plan!”

              • Product planning is different than “what we need to build to meet that value in the product”. Product planning should have at least 1 cycle before you bring engineers into the room. The engineers are here to help you understand risks and timelines of each thing you want to build, to help the customer prioritize to achieve the most value. The person in charge of the team needs to have the authority to change product scope based on how the software is progressing.
              • Responding to change doesn’t mean we shouldn’t have a rough plan. “Planning” is not 50 pages in a document and another 50 of UML. It could be as simple as paper or dry-erase board mockups.
              • We should still routinely plan and adjust the plan, because it helps inform our decisions and make us think about the product and how to write code to meet these product objectives. However, the plan won’t be written in stone, so we shouldn’t spend exorbitant amounts of time on it, or continue following it despite warning signs to how bad it’s turning out.
              • Assigning us more “points” than we’ve ever done before in a sprint doesn’t make us work any faster. If we’re not going to meet a deadline that no one created a rough plan to meet and you didn’t change the scope of work to figure out how to meet it, we’re not going to meet it.
              1. 3

                For the last couple months I’ve been working on this project: I’m interviewing people who have worked as both a traditional engineer and a software developer, in hopes of learning more about the differences. One recent person told me that Agile isn’t a new idea: you see something like it in almost every engineering field. Software people just think we invented it.

                The upshot is that there are issues with agile-like frameworks. Issues that can be handled, no doubt. But since we think agile is uniquely ours, we’re rediscovering all those problems when we really don’t have to.

                I couldn’t get a good explanation on what those issues are from that guy. But I suspect they’d be very different from the problems here, which are basically “you’re doing it wrong”.

                1. 1

                  On Mary Poppendieck’s lean software development, she quotes the experience of other design and engineering fields and when they apply to software. A way more sane approach to agile than most.

                2. 2

                  Maybe if software engineers spent more time actually learning what agile was, they’d realize that they actually don’t like the fake agile that they are being sold by their companies. Maybe they’d finally throw that Jira trash out the door and use something effective. Maybe agile isn’t the problem.

                  Okay. In this case, maybe not maybe.

                    1. 0

                      Not really. You can do it in a lot of ways, but a lot of people do what is called “waterfall” and pretend it’s agile.

                      1. 1

                        I think you are proving the point that @federico3 was making :)

                        1. 1

                          Exactly.

                          1. 0

                            No. Again, there are differences between the methodologies. You can’t just take a waterfall process and call it agile and then tell everyone they don’t understand.

                            If you don’t know the details of the processes which I am referring to in order to make the assumption of being a “no true scotsman” argument then assuming that I’m wrong is plainly ignorant.

                            I didn’t say that everyone or even most people do this. I just said that it happens. Your argument here relies on the idea that everyone who says they’re doing agile is actually doing agile - and that they are never doing waterfall. It is plainly wrong, and absolutely only supported by ignorance.

                            Since, however, you seem to be so sure that this is the actual issue, feel free to enlighten me on the situation which I am referring to is agile and how I am representing the issue incorrectly - since you’ve already established such. I’d love to learn from your extra-sensory perception of my experiences.

                    2. 1

                      The problem with agile is that it’s deep down just an ugly old school landing page with generic sentences written by a bunch of white guys having some brewskis in a sky resort. So anyone can see whatever they want from it.