5 ms·

I still remain totally unconvinced that 'Agile' is broken, or has failed. I have worked in places that do FakeAgile, and places that do GoodAgile, and there are

I still remain totally unconvinced that 'Agile' is broken, or has failed. I have worked in places that do FakeAgile, and places that do GoodAgile, and there are two conclusions: 1. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want. 2. When companies do agile development well, it is effective at solving some of the worst problems that software development faces. Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is. - Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves. - Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback. - 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team. - Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers. - Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve. That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand-ups, or whatever. Agile development works well if you're agile. It's not a set of rules that must be followed – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.

eropple 12y ago
> That's the core of Scrum, and I don't see what's wrong with it. Where does professional development come in, my true Scotsman?
- giaour 12y ago
  From what I've seen, professional development in a scrum shop means moving from junior developer to people manager. If you want to keep coding, you're expected to leave within two years.
  - eropple 12y ago
    Agreed (though maybe not "two years"), and that was what I was getting at. Scrum is not a system for investing in people--and we need to do that. It's a fairly exploitative mode of organization and this industry's largely uncritical adoption of it is something we don't look at particularly often or with much real gusto.
    - matthewmacleod 12y ago
      Scrum is not a system for investing in people You're right – Scrum is a process framework for developing software. That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development. Bad culture is bad culture, regardless of development methodology.
      - giaour 12y ago
        What you're essentially telling your engineers is that A) doing their job has nothing to do with getting better at their job, and B) if they want to advance beyond the junior engineer level, they will have to do so on their own time. I've seen this referred to as "terminal juniority." Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
        eropple 12y ago
        Fantastic post, and I agree. I've always been in a weird place professionally because I came out of school at a somewhat-above-junior level and so I've been in an interesting position to watch companies try to mold developers. There's that "five years of experience"/"one year of experience, five times" thing people sometimes refer to, and Scrum seems tailored to doing the latter. Terminal juniority is an amazing term for that. Thanks.
- matthewmacleod 12y ago
  What do you consider to be professional development? I'm not clear why you think it doesn't fit in there.
RogerL 12y ago
"That's the core of Scrum, and I don't see what's wrong with it." Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on. Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt. 2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks. Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts. Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on). Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line. Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that would result in a functioning system? No where. Why expect it to work in running projects. The agile manifesto didn't. They expected thinking and agility, not fixed 2 week sprints, no matter what. People over process. Scrum is a process. Enough said?
dragonwriter 12y ago
> Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development. > Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve. This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better. If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.
- AnimalMuppet 12y ago
  > and revise your processes accordingly This. So much this. Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration. If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part. Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful. Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't. Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.

eropple 12y ago

> That's the core of Scrum, and I don't see what's wrong with it. Where does professional development come in, my true Scotsman?

giaour 12y ago
From what I've seen, professional development in a scrum shop means moving from junior developer to people manager. If you want to keep coding, you're expected to leave within two years.
- eropple 12y ago
  Agreed (though maybe not "two years"), and that was what I was getting at. Scrum is not a system for investing in people--and we need to do that. It's a fairly exploitative mode of organization and this industry's largely uncritical adoption of it is something we don't look at particularly often or with much real gusto.
  - matthewmacleod 12y ago
    Scrum is not a system for investing in people You're right – Scrum is a process framework for developing software. That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development. Bad culture is bad culture, regardless of development methodology.
    - giaour 12y ago
      What you're essentially telling your engineers is that A) doing their job has nothing to do with getting better at their job, and B) if they want to advance beyond the junior engineer level, they will have to do so on their own time. I've seen this referred to as "terminal juniority." Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
      - eropple 12y ago
        Fantastic post, and I agree. I've always been in a weird place professionally because I came out of school at a somewhat-above-junior level and so I've been in an interesting position to watch companies try to mold developers. There's that "five years of experience"/"one year of experience, five times" thing people sometimes refer to, and Scrum seems tailored to doing the latter. Terminal juniority is an amazing term for that. Thanks.
matthewmacleod 12y ago
What do you consider to be professional development? I'm not clear why you think it doesn't fit in there.

RogerL 12y ago

"That's the core of Scrum, and I don't see what's wrong with it." Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on. Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt. 2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks. Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts. Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on). Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line. Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that would result in a functioning system? No where. Why expect it to work in running projects. The agile manifesto didn't. They expected thinking and agility, not fixed 2 week sprints, no matter what. People over process. Scrum is a process. Enough said?

dragonwriter 12y ago

> Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development. > Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve. This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better. If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.

AnimalMuppet 12y ago
> and revise your processes accordingly This. So much this. Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration. If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part. Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful. Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't. Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.