9 ms·

Fixing Scrum (2019)

59 points by bobm_kite9 7y ago

runawaybottle 7y ago
I’ve become extremely apathetic towards Agile. Whatever, this how a company needs to manage it, fine. I’m not wasting time wrapping my head around it. Tshirt size or point poker stuff or ‘As a developer, I would like to’ stories, like seriously, whatever. It’s not going anywhere and doesn’t always make sense, so I just suck it up and truck along. Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks.
- ketamine__ 7y ago
  Jira is hell. There are now multiple boards, issues cloned from one board to another, and tons of lanes. We'll probably add more because documenting every detail is now the goal. We are a small team that is spending many hours per week having discussions on process. We even hired a consultant to come in and evaluate things. Jira seems to help stakeholders and product owners conceptualize the work and timelines but I see zero productivity gains from continuously evaluating and tweaking Jira.
  - elric 7y ago
    Jira is just a tool. Blame the players, not the game. Or, in this case; the users, not the tool. Developers just want to know what they're supposed to be working on. Managerial types want to know what people are working on, when things will be done, and goodness knows what else. You obviously need to give developers the room and time to get actual development done. But at the same time, unless you work for a truly tiny company, there's always going to be some level of crap reporting that feels useless to most developers, but is important to someone else. It's hard to strike a balance that works for everyone.
    - willis936 7y ago
      When the shape of the tool is bloat and unnecessary overhead, is it still not the tool’s fault?
    - eberyvody 7y ago
      blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool. a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there. edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.
- deanCommie 7y ago
  The thing is, it's not all about you. Source: I am a developer like you that has the exact same instinctual attitude about it. Here is why it's wrong. Project managers need to build schedules so they could coordinate dependent features across multiple teams. Marketing needs to orchestrate launch announcements and fixed activities that are not quite as inflexible as printing millions of CD-ROMs, but still require dates. And managers, ultimately, are held responsible for a project delivery, so they need to track it's progress, understand what things are ahead (lol) or behind (yup), which areas need help from more people, more seniority, or less scope. All of this needs to come together for any successful project of any reasonable complexity. None of this is new, or news to you, of course. Here's the part you're missing: The way things USED to work was that PMs, Marketing, Sales, and Managers would come up with processes that worked for them, and forced it on development teams, regardless of how it made the devs feel. Agile was an attempt for the developers to take ownership of their process bottoms-up. Planning poker, standups, sprints, all these ideas were invented by developers to make their lives EASIER not harder. And none of it was supposed to be panacea - the only way to do things. Each team is supposed to figure out the right balance of what works for them. So don't be apathetic. You are an active contributor to this process. Take pride in the fact that you have a lot of autonomy about how to define your project structure in an agile environment. Change what you don't like, and figure out what works the best for your team.* * Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.
  - TsomArp 7y ago
    Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own way of delivering software which basically was: meet with users/stakeholders, talk about what they need, build a first version in 2 to 4 weeks, release, test, adjust, repeat. For me it makes so much sense agile that I don't get why some devs don't understand the beauty and simplicity of it. If you want to know more about the why of the standup, and what is the idea behind it, read Borland's tell: https://www.scruminc.com/origins-daily-standup/ https://www.scruminc.com/origins-daily-standup/
- cle 7y ago
  > Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks. Working with you might be as painful for others as working with agile is for you... All these things (scrum, agile, etc.) are just mechanisms for working effectively as a group. Like all tools, some work better in certain situations than others, and they should be adopted deliberately with an understanding of the tradeoffs. This is traditionally where "management" falls short. It doesn't have to be this way. Accept that there are no silver bullets or always-correct methodologies, just a hodgepodge of techniques for helping people work better together.
  - runawaybottle 7y ago
    Like everything in life, depends on who’s asking.
  - oxfordmale 7y ago
    The problem is that is now how Scrum is sold. If you claim Scrum doesn't work for your particular team/project, the usual answer is that you are not implementing Scrum correctly.
Terretta 7y ago
Title close to click-bait or false advertising, since this article just argues Scrum is broken. Suggests next article will get into fixing. > If the thesis that “90% of everything is waste” then Planning Poker is also a waste, and we should devise a planning process to avoid this. > In the next article we’ll look at how we might do that.
- wpietri 7y ago
  In case anybody wants an answer to that, here's mine: Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range. Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable. Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people. But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.
- bobm_kite9 7y ago
  Author here. Sorry you think that. I see the article title has been changed, although I wrote this about 3 weeks ago so I'm not sure why it's been labelled as (2019). This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution. Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline. I'll look forward to your thoughts on the next one.
brightball 7y ago
The issue with Scrum is everything revolving around 2 week sprints. That doesn’t allow for much in terms of variability, longer term scheduling, or planning dependencies across multiple teams. Plus, in order to try to make the commitment/forecast accurate you have to invest a hefty amount of planning time every 2 weeks. The Scaled Agile (SAFe) approach is dramatically better here. You plan 8-12 weeks at a time across all teams and invest heavily in planning for 2-3 days of that entire time period. The planning time is synced up for all dev teams so they can communicate and work out cross dependencies. The other perk here is that you’re goal is to commit to the 12 weeks and not every 2 weeks. That allows for more ups and downs and there’s a built in 1.5 week buffer at the end specifically to account for overrun. You end up with a clear picture of what’s coming in the next quarter or so without flavor of the week course changes outside of a significant emergency.
- Ididntdothis 7y ago
  To be honest when I saw the diagram for scaled agile https://www.scaledagileframework.com/ https://www.scaledagileframework.com/ the first my BS meter went off big time :). It definitely doesn’t deserve the word “agile” in it. It feels more like the management pipe dream of the perfectly predictable machine for software development.
  - lostcolony 7y ago
    Yup. And the OP did nothing to dissuade me from that. 12 weeks instead of 2 isn't actually helpful; the whole goal of the 2 week sprint was to find a balance between minimal amount of time needed to recognize 'we're going to take longer than anticipated', and actually being able to deliver something useful. Going to 12 just means that you won't recognize things are slipping until the quarter is up.
    - brightball 7y ago
      You still break things into 2 week iterations over the 8-12 weeks. You still check in on things, get feedback and determine if changes or pivoting is needed. Nothing stops that. What it does stop is all of the planning meetings crammed in every 2 week time period while also giving a forum for planning between all of your other teams. There’s no advantage of scrum that is denied with SAFe. It just gets rid of most of the problems that I’ve experienced with it in the last 10-15 years.
eberyvody 7y ago
ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :) mostly agree with the premise though, and I'll add that "sprint" is insane nomenclature for something that you do continuously week-in and week out. my question for the author (and ya'll) is how to reconcile the time-waste of estimating with the fact that you do indeed need some estimate of how long something is going to take in order to decide whether you should prioritize doing it (we like RICE [0]). as the designer on a startup team, i'm not going to push for designing / building some crazy VR UI no matter how much we hear a customer asking for it, but i'll definitely design some 3d button transform hover states or other small finesse if the front-end eng says it's easy to implement. i'm sure i can think of a less extreme example, but not today. [0]: https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ https://www.intercom.com/blog/rice-simple-prioritization-for...
- bobm_kite9 7y ago
  > ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :) Author here. Yes, another comment made the same point. But I'm glad you feel what I covered was eloquent. Often, diagnosing exactly what the problem is takes you a long way towards solving it. As I said in the other reply, I will post the follow-up to this article in a few weeks which will outline where I am going with this: I'm building a multi-part series looking at estimating in software development, so Sprints are an important aspect.
- ellius 7y ago
  My most recent team ran a version of XP, and I found IPM (iteration planning meeting) to be one of the most effective and important things we did. We had a very good back and forth with our Product Manager, with conversations usually going something like this: PM: Let's go through our prioritized features. First we would like Feature A. Team: That's probably easy, we can do it in a day or so. PM: Great. Next we need Feature B. I know this one looks a little more complicated. Team: Yeah, that's more like a week. PM: That probably isn't worth it to me. We can probably push this feature back a couple releases, and maybe take out part of it. Team: Would it help if we just did Part X? That seems like it would give you most of the value and it would be much easier. And so on. The constant cost-benefit analysis, reprioritization, and rescoping was a great lever and made the team very productive. The other 4 things, all related I think, that made us effective were: • Everyone sitting together. I could go ask the designer or PM a clarifying question at any time. • TDD. I would constantly start to write a test and realize that something didn't make sense—some assumptions were conflicting, or we needed to do another story before the one I was working, etc. • Pairing. Many times I'd have written the test, had cleared my plan with the PM, and my pairing partner would point out a different perspective or catch one of the things I described above. • Frequent releases, about quarterly at first and down to bi-weekly at one point. In all cases, what we were really doing is optimizing the value of NOT doing things. We were helping the PM understand her costs, but we were also helping her eliminate huge chunks of wasteful work, e.g. building things users didn't want, things that didn't integrate well, and so on. Estimating was a piece of it, but it was really the buy-in from the business to accept our estimates and more importantly to trust us as partners in the scoping and planning process, and doing that process fluidly, that made us successful.
lostcolony 7y ago
'How can we, as software developers, minimise the chance of building the wrong thing?' Make sure you're hiring the right product people? I've never "built the wrong thing"; I -have- been told to solve the wrong problem, or been given incorrect information, or been left with unresolvable ambiguities from product that I've just had to arbitrarily pick between. That may seem like a picky distinction, but it matters. I've never gone back and said "Huh, yeah, you defined the problem really well, then were super responsive with my following up with you, but I somehow wrote code that did something completely different to what we specced out together". Invariably it's been product not knowing what they actually want, or being hellbent to build something stupid (massive amounts of effort for no revenue impact, etc).
- hackbinary 7y ago
  Honestly, Project/Product/Program staff, BAs, and Testers perform an important function when properly aligned and cooperating with development staff. When done well, they keep pesky 'business side's owners out of the way so the technical workers can get on with development work.
- bobm_kite9 7y ago
  Isn't it still the wrong thing, even if you built exactly what was asked for?
- eberyvody 7y ago
  never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng. in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.
  - Ididntdothis 7y ago
    Yes, people have to work together and all roles have something important to contribute. I have been in plenty of situations where product managers and users tried to solve a problem and I could guide the discussion towards solutions that made sense development wise and also satisfied the users. Having customers or product people defining solutions alone is a surefire recipe for misdesigned systems.
oxfordmale 7y ago
The only way you can fix scrum is by burning it on the stake. One of the core principles of Agile is to recognize that the best work emerges from self-organized teams. however, most scrum methodologies completely ignore this and put control back in the hands of senior management by introducing heavy handed processes (daily stand ups, retrospective, bi-weekly planning sessions, scrum masters, etc). You know you are in trouble when a team introduces a definition of done and you are in deep trouble when senior management starts discussion burn down rate charts of completely made up story points.
- aivosha 7y ago
  could not agree more!
- sime2009 7y ago
  I've done scrum for years and have very rarely had a manager involved in any of those processes, and I have certainly never had senior management involved. Those processes exist for the benefit of the team and for the team to 'run' itself. There is no reason for management to be there. Stop doing that.
  - nitely 7y ago
    I agree. Scrum is about self-organized teams. Managers are not part of the Scrum team, in fact, they are not allowed to speak in any of those meetings (if they choose to assist at all). I think the main problem here is a lot of companies do this weird hybrid where Scrum processes are somewhat followed, but managers keep managing the team and sometimes even taking the role of product owner and/or scrum master as well, and that just doesn't work.
    - p_l 7y ago
      That's why sometimes you have people (like me) speeding through the daily standup so that the manager will be late...
  - oxfordmale 7y ago
29athrowaway 7y ago
Take a look at the most lasting, highly successful open source projects used by most companies today. They have something in common: - Full-time software engineering managers? 0% - Full-time product managers? 0% - Full-time project managers? 0% - Committed engineers focusing in implementation working on flexible time schedules: 100% The true inefficiencies that managers spend their careers looking for, are right there in front of the mirror. https://youtu.be/rQKis2Cfpeo?t=114 https://youtu.be/rQKis2Cfpeo?t=114
- pinkfoot 7y ago
  They also all share not having to make payroll every 30 days.
  - 29athrowaway 7y ago
    They certainly help your ability to make payroll every 30 days. Some open source projects are sponsored or backed by foundations, and contributors do get paid.
deleted 7y ago
[deleted]

Fixing Scrum (2019)

59 points by bobm_kite9 7y ago

I’ve become extremely apathetic towards Agile. Whatever, this how a company needs to manage it, fine. I’m not wasting time wrapping my head around it. Tshirt size or point poker stuff or ‘As a developer, I would like to’ stories, like seriously, whatever. It’s not going anywhere and doesn’t always make sense, so I just suck it up and truck along. Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks.

ketamine__ 7y ago
Jira is hell. There are now multiple boards, issues cloned from one board to another, and tons of lanes. We'll probably add more because documenting every detail is now the goal. We are a small team that is spending many hours per week having discussions on process. We even hired a consultant to come in and evaluate things. Jira seems to help stakeholders and product owners conceptualize the work and timelines but I see zero productivity gains from continuously evaluating and tweaking Jira.
- elric 7y ago
  Jira is just a tool. Blame the players, not the game. Or, in this case; the users, not the tool. Developers just want to know what they're supposed to be working on. Managerial types want to know what people are working on, when things will be done, and goodness knows what else. You obviously need to give developers the room and time to get actual development done. But at the same time, unless you work for a truly tiny company, there's always going to be some level of crap reporting that feels useless to most developers, but is important to someone else. It's hard to strike a balance that works for everyone.
  - willis936 7y ago
    When the shape of the tool is bloat and unnecessary overhead, is it still not the tool’s fault?
  - eberyvody 7y ago
    blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool. a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there. edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.
deanCommie 7y ago
The thing is, it's not all about you. Source: I am a developer like you that has the exact same instinctual attitude about it. Here is why it's wrong. Project managers need to build schedules so they could coordinate dependent features across multiple teams. Marketing needs to orchestrate launch announcements and fixed activities that are not quite as inflexible as printing millions of CD-ROMs, but still require dates. And managers, ultimately, are held responsible for a project delivery, so they need to track it's progress, understand what things are ahead (lol) or behind (yup), which areas need help from more people, more seniority, or less scope. All of this needs to come together for any successful project of any reasonable complexity. None of this is new, or news to you, of course. Here's the part you're missing: The way things USED to work was that PMs, Marketing, Sales, and Managers would come up with processes that worked for them, and forced it on development teams, regardless of how it made the devs feel. Agile was an attempt for the developers to take ownership of their process bottoms-up. Planning poker, standups, sprints, all these ideas were invented by developers to make their lives EASIER not harder. And none of it was supposed to be panacea - the only way to do things. Each team is supposed to figure out the right balance of what works for them. So don't be apathetic. You are an active contributor to this process. Take pride in the fact that you have a lot of autonomy about how to define your project structure in an agile environment. Change what you don't like, and figure out what works the best for your team.* * Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.
- TsomArp 7y ago
  Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own way of delivering software which basically was: meet with users/stakeholders, talk about what they need, build a first version in 2 to 4 weeks, release, test, adjust, repeat. For me it makes so much sense agile that I don't get why some devs don't understand the beauty and simplicity of it. If you want to know more about the why of the standup, and what is the idea behind it, read Borland's tell: https://www.scruminc.com/origins-daily-standup/ https://www.scruminc.com/origins-daily-standup/
cle 7y ago
> Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks. Working with you might be as painful for others as working with agile is for you... All these things (scrum, agile, etc.) are just mechanisms for working effectively as a group. Like all tools, some work better in certain situations than others, and they should be adopted deliberately with an understanding of the tradeoffs. This is traditionally where "management" falls short. It doesn't have to be this way. Accept that there are no silver bullets or always-correct methodologies, just a hodgepodge of techniques for helping people work better together.
- runawaybottle 7y ago
  Like everything in life, depends on who’s asking.
- oxfordmale 7y ago
  The problem is that is now how Scrum is sold. If you claim Scrum doesn't work for your particular team/project, the usual answer is that you are not implementing Scrum correctly.

Terretta 7y ago

Title close to click-bait or false advertising, since this article just argues Scrum is broken. Suggests next article will get into fixing. > If the thesis that “90% of everything is waste” then Planning Poker is also a waste, and we should devise a planning process to avoid this. > In the next article we’ll look at how we might do that.

wpietri 7y ago
In case anybody wants an answer to that, here's mine: Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range. Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable. Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people. But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.
bobm_kite9 7y ago
Author here. Sorry you think that. I see the article title has been changed, although I wrote this about 3 weeks ago so I'm not sure why it's been labelled as (2019). This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution. Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline. I'll look forward to your thoughts on the next one.

brightball 7y ago

The issue with Scrum is everything revolving around 2 week sprints. That doesn’t allow for much in terms of variability, longer term scheduling, or planning dependencies across multiple teams. Plus, in order to try to make the commitment/forecast accurate you have to invest a hefty amount of planning time every 2 weeks. The Scaled Agile (SAFe) approach is dramatically better here. You plan 8-12 weeks at a time across all teams and invest heavily in planning for 2-3 days of that entire time period. The planning time is synced up for all dev teams so they can communicate and work out cross dependencies. The other perk here is that you’re goal is to commit to the 12 weeks and not every 2 weeks. That allows for more ups and downs and there’s a built in 1.5 week buffer at the end specifically to account for overrun. You end up with a clear picture of what’s coming in the next quarter or so without flavor of the week course changes outside of a significant emergency.

Ididntdothis 7y ago
To be honest when I saw the diagram for scaled agile https://www.scaledagileframework.com/ https://www.scaledagileframework.com/ the first my BS meter went off big time :). It definitely doesn’t deserve the word “agile” in it. It feels more like the management pipe dream of the perfectly predictable machine for software development.
- lostcolony 7y ago
  Yup. And the OP did nothing to dissuade me from that. 12 weeks instead of 2 isn't actually helpful; the whole goal of the 2 week sprint was to find a balance between minimal amount of time needed to recognize 'we're going to take longer than anticipated', and actually being able to deliver something useful. Going to 12 just means that you won't recognize things are slipping until the quarter is up.
  - brightball 7y ago
    You still break things into 2 week iterations over the 8-12 weeks. You still check in on things, get feedback and determine if changes or pivoting is needed. Nothing stops that. What it does stop is all of the planning meetings crammed in every 2 week time period while also giving a forum for planning between all of your other teams. There’s no advantage of scrum that is denied with SAFe. It just gets rid of most of the problems that I’ve experienced with it in the last 10-15 years.

eberyvody 7y ago

ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :) mostly agree with the premise though, and I'll add that "sprint" is insane nomenclature for something that you do continuously week-in and week out. my question for the author (and ya'll) is how to reconcile the time-waste of estimating with the fact that you do indeed need some estimate of how long something is going to take in order to decide whether you should prioritize doing it (we like RICE [0]). as the designer on a startup team, i'm not going to push for designing / building some crazy VR UI no matter how much we hear a customer asking for it, but i'll definitely design some 3d button transform hover states or other small finesse if the front-end eng says it's easy to implement. i'm sure i can think of a less extreme example, but not today. [0]: https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ https://www.intercom.com/blog/rice-simple-prioritization-for...

bobm_kite9 7y ago
> ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :) Author here. Yes, another comment made the same point. But I'm glad you feel what I covered was eloquent. Often, diagnosing exactly what the problem is takes you a long way towards solving it. As I said in the other reply, I will post the follow-up to this article in a few weeks which will outline where I am going with this: I'm building a multi-part series looking at estimating in software development, so Sprints are an important aspect.
ellius 7y ago
My most recent team ran a version of XP, and I found IPM (iteration planning meeting) to be one of the most effective and important things we did. We had a very good back and forth with our Product Manager, with conversations usually going something like this: PM: Let's go through our prioritized features. First we would like Feature A. Team: That's probably easy, we can do it in a day or so. PM: Great. Next we need Feature B. I know this one looks a little more complicated. Team: Yeah, that's more like a week. PM: That probably isn't worth it to me. We can probably push this feature back a couple releases, and maybe take out part of it. Team: Would it help if we just did Part X? That seems like it would give you most of the value and it would be much easier. And so on. The constant cost-benefit analysis, reprioritization, and rescoping was a great lever and made the team very productive. The other 4 things, all related I think, that made us effective were: • Everyone sitting together. I could go ask the designer or PM a clarifying question at any time. • TDD. I would constantly start to write a test and realize that something didn't make sense—some assumptions were conflicting, or we needed to do another story before the one I was working, etc. • Pairing. Many times I'd have written the test, had cleared my plan with the PM, and my pairing partner would point out a different perspective or catch one of the things I described above. • Frequent releases, about quarterly at first and down to bi-weekly at one point. In all cases, what we were really doing is optimizing the value of NOT doing things. We were helping the PM understand her costs, but we were also helping her eliminate huge chunks of wasteful work, e.g. building things users didn't want, things that didn't integrate well, and so on. Estimating was a piece of it, but it was really the buy-in from the business to accept our estimates and more importantly to trust us as partners in the scoping and planning process, and doing that process fluidly, that made us successful.

lostcolony 7y ago

'How can we, as software developers, minimise the chance of building the wrong thing?' Make sure you're hiring the right product people? I've never "built the wrong thing"; I -have- been told to solve the wrong problem, or been given incorrect information, or been left with unresolvable ambiguities from product that I've just had to arbitrarily pick between. That may seem like a picky distinction, but it matters. I've never gone back and said "Huh, yeah, you defined the problem really well, then were super responsive with my following up with you, but I somehow wrote code that did something completely different to what we specced out together". Invariably it's been product not knowing what they actually want, or being hellbent to build something stupid (massive amounts of effort for no revenue impact, etc).

hackbinary 7y ago
Honestly, Project/Product/Program staff, BAs, and Testers perform an important function when properly aligned and cooperating with development staff. When done well, they keep pesky 'business side's owners out of the way so the technical workers can get on with development work.
bobm_kite9 7y ago
Isn't it still the wrong thing, even if you built exactly what was asked for?
eberyvody 7y ago
never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng. in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.
- Ididntdothis 7y ago
  Yes, people have to work together and all roles have something important to contribute. I have been in plenty of situations where product managers and users tried to solve a problem and I could guide the discussion towards solutions that made sense development wise and also satisfied the users. Having customers or product people defining solutions alone is a surefire recipe for misdesigned systems.

oxfordmale 7y ago

The only way you can fix scrum is by burning it on the stake. One of the core principles of Agile is to recognize that the best work emerges from self-organized teams. however, most scrum methodologies completely ignore this and put control back in the hands of senior management by introducing heavy handed processes (daily stand ups, retrospective, bi-weekly planning sessions, scrum masters, etc). You know you are in trouble when a team introduces a definition of done and you are in deep trouble when senior management starts discussion burn down rate charts of completely made up story points.

aivosha 7y ago
could not agree more!
sime2009 7y ago
I've done scrum for years and have very rarely had a manager involved in any of those processes, and I have certainly never had senior management involved. Those processes exist for the benefit of the team and for the team to 'run' itself. There is no reason for management to be there. Stop doing that.
- nitely 7y ago
  I agree. Scrum is about self-organized teams. Managers are not part of the Scrum team, in fact, they are not allowed to speak in any of those meetings (if they choose to assist at all). I think the main problem here is a lot of companies do this weird hybrid where Scrum processes are somewhat followed, but managers keep managing the team and sometimes even taking the role of product owner and/or scrum master as well, and that just doesn't work.
  - p_l 7y ago
    That's why sometimes you have people (like me) speeding through the daily standup so that the manager will be late...
- oxfordmale 7y ago

29athrowaway 7y ago

Take a look at the most lasting, highly successful open source projects used by most companies today. They have something in common: - Full-time software engineering managers? 0% - Full-time product managers? 0% - Full-time project managers? 0% - Committed engineers focusing in implementation working on flexible time schedules: 100% The true inefficiencies that managers spend their careers looking for, are right there in front of the mirror. https://youtu.be/rQKis2Cfpeo?t=114 https://youtu.be/rQKis2Cfpeo?t=114

pinkfoot 7y ago
They also all share not having to make payroll every 30 days.
- 29athrowaway 7y ago
  They certainly help your ability to make payroll every 30 days. Some open source projects are sponsored or backed by foundations, and contributors do get paid.

deleted 7y ago

[deleted]