55 ms·

Scrum disempowers developers

• Robin_Message 8y ago
  OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 https://news.ycombinator.com/item?id=16892307 ). I'm trying to take a bit more of a systematic, longer, researched and justified view of things, so any feedback is very welcome!
  • darahayes 8y ago
    OP do you work at my company by any chance? This is scarily accurate.
  • jacques_chester 8y ago
    What I've mostly noticed is that when people show up with cynicism or actual anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved (edit: though this might be sample bias, as Scrum is by far the most popular methodology). I'm sure it's working really well for some folks. A large fraction of the magic of any agile system is the folks involved and their familiarity and experience with it. I work for Pivotal, our wheelbarrow is XP with Lean trimmings. I've seen it up close for 4 years in both consulting and large product development and -- summarising -- it works. But no small part of it working is the context. Our context is that we hire carefully and that the entire organisation is interested in, and supportive of, the way we work. It is fantastically easier to do agile well in an environment where it is already done well (which is why we ask our clients to come work in our office). If I had to pick the most destructive part of Scrum, it's the sprint commitment. Yes, it's called forecasts now, but folks are held to it anyhow. All it does is create a dynamic which generates either waste or burnout. Software should be releasable at all times, not once every two weeks. New features should be presented to a Product Manager as they are done done, not according to what is an essentially coincidental cadence chosen because two weeks is easy to mark on a calendar. At Pivotal the closest we came to sprints was setting up a quarterly release cycle for our flagship product, PCF. The first few were a mess and we massively overshot our planned dates several times. We switched to something much closer to our normal way of working: release trains. Every quarter we make a release. If a component product has a feature ready at that time, the feature gets shipped. If it doesn't, it doesn't. And that's that. We already have a lot of our customers who've adopted automation to update their PCF platforms for patches on a rolling basis. My fond secret hope is that one day, we'll be able to drop the quarterly release cycle as well and just ship things when they're ready to ship.
    • mikekchar 8y ago
      > If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following: - Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead. - Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water. -Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment. - Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story. In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems: - Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team. -There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this. In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point. Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.
  • ysavir 8y ago
    Here's my one piece of feedback: It's all well and good if you look at places where Scrum has failed, but if you don't look at places where Scrum has succeeded, and offer an analysis there, the research is meaningless. Currently it feels like you're limiting your scope of research to places where Scrum has failed. Is it any surprise, then, that your research has supported your thesis?
• MrBuddyCasino 8y ago
  Are you working in feature factory? Chances are you're doing Scrum: https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2 https://hackernoon.com/12-signs-youre-working-in-a-feature-f...
  • jacques_chester 8y ago
    This is a great article.
  • sprky 8y ago
    Great article, but but none of it has anything to do with scrum.
    • MrBuddyCasino 8y ago
      True, but they're synergistic - Scrum is the natural choice for a Feature Factory and reinforces all the bad aspects of it, Kanban much less so.
• ordinaryperson 8y ago
  What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent? Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust. No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.
  • acdha 8y ago
    > What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent? Isn’t he the same guy who’s been learning that more process is necessary to make cars safely and on-schedule? I’d be reluctant to draw any broad conclusion from one optimistic aphorism.
    • smackay 8y ago
      But the essential difference is that process applied to manufacturing is about repeatability, quality, reliability etc. where process in software is more about communication. Eventually, maybe, a software process will be more like a manufacturing one but the variation in technologies, techniques and general fashion make that hard - even in limited areas such as CRUD web apps. I think you'd get the same outcomes with a manufacturing process as we currently get with software if every year you changed the engines, materials, electronics and transmissions.
      • watwut 8y ago
        Awesome software development process that is not about communication: testing by testers. Also code and documentation review. Also, keeping tasks in tracker and having version controll. Etc.
        • jrs95 8y ago
          Code review definitely is about communication. That’s arguably it’s biggest benefit. The author could test something himself, but code review facilitates a conversation and keeps people on the same page.
• tuke 8y ago
  This is fine as an opinion piece and a close reading of parts of the scrum guide, but some kind of evidence (even reports via surveys) would help.
• majewsky 8y ago
  I encourage the author to load this post over a spotty 2G connection. I have the feeling that some paragraphs (mainly quotes) were just missing for me, maybe because of failed XHRs. Also, it takes much longer to load despite being plain text.
• js8 8y ago
  My biggest beef with Scrum (and why I think it's a scam) is that they renamed everything, all the processes. Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care of whether the thing is technically feasible, what technologies are used and what technical trade-offs are made. And there was a vast literature and discussion about how these three sides affect the result of the project, and how to solve these problems. Unfortunately, Scrum, renaming everything, acts as if the history of project management doesn't exist. And if you forget history, how are you supposed to learn from it? That makes it easy to sell snake-oil. I frequently hear, for instance, that scrum master is not a project manager, despite him having some responsibilities in this area. And as the blog post also expounds, there is no recognition for these three different sides of each project in Scrum (ironically, there is some recognition of that in Scrum derivatives such as Scaled Agile Framework, for instance, modulo nonsensical renaming of the roles).
  • tootie 8y ago
    Scrum didn't rename any of them. They added the roles of scrum master and product owner but those are roles that can be assigned to people with traditional titles in addition to their normal roles.
    • blub 8y ago
      The scrum master and PO should explicitly not also be the PM, there's a huge conflict of interest.
      • tootie 8y ago
        PM can be scrum master. I've done it plenty of times. The entire scrum team should be aligned around the same objectives so a conflict of interest is not possible. The PO is outside the team and is the only one who should avoid wearing multiple hats.
  • deleted 8y ago
• lispm 8y ago
  > Finally we have this self-organised, cross-functional, non-hierarchical, essentially amorphous development team. They are meant to be self organising, with no one telling them how to build the product backlog. However, they have limited or no say over what is top of the product backlog, pressure to deliver something sprint-after-sprint, and no-one with the authority to balance the product owner and advocate for developing with higher quality. In fact, the whole way Scrum views the development team is completely flawed given how real organisations operate. Setting up the scene to fail, and then, surprise, it fails. Blame it on scrum.
  • conatus 8y ago
    "no-one with the authority to balance the product owner and advocate for developing with higher quality" In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success.
    • matthewmacleod 8y ago
      In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success. Yep, I fail to understand the problem with this. A product owner who doesn't respond to pressure for technical quality is a bad product owner – end of story.
    • mlthoughts2018 8y ago
      These types of replies always strike me as No True Scotsman fallacies, which are rife in Agile & Scrum. “No true Scrum team would do X.” “No functional team would disempower people...” At some point though, Agile & Scrum cannot be propped up like that. When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure. The tool (Agile & Scrum) is the correlate here. Somehow it’s always showing up co-located with these problems, but we’re never honest enough to step back and admit maybe, sometimes, with enough evidence, correlation can be related to causation in this case.
• matthewmacleod 8y ago
  I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups. There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value. I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in <other process>" is more valuable than "If you have a bad team then Scrum is bad".
  • conatus 8y ago
    > Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.
    • yebyen 8y ago
      > done right it is effective. That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum? I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover. I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.) And > apparently it has to involve something called “Jira”. hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better. Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira. We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial. I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team. I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.
• robin_reala 8y ago
  For me Scrum is like training wheels for agile. It’s restrictive and hinders progress at any real speed, but gives you the framework to start producing stuff in an agile way. Once you out grow it there are plenty of better methodologies, include the proper agile way which is that the structure of your product management is also a component to be iterated. It’s difficult to jump straight in at that point though. Just a shame that most teams’ processes crystallise around Scrum. Working with self described Scrum masters is painful as they’ve built themselves into a box they can’t see out of.
• matt_s 8y ago
  The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together. There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers. Two ways to tackle technical debt in projects: 1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever. 2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months. An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.
  • matthewmacleod 8y ago
    I would say that estimation isn't so much about predicting completion as understanding hidden assumptions in the team. We sometimes find that engineers have entirely different concepts of how a particular feature or change needs to be implemented. Estimation – planning poker in particular – is a great way to reveal that and start exploring what the reasons are.
    • matt_s 8y ago
      It is a good facilitator of that conversation but you don't need to do estimating to have that conversation about implementation details. Once a team arrives at common patterns of implementing things then those conversations really only need to happen for new implementations or integrations with other systems.
    • zelos 8y ago
      "At least we're not doing planning poker" was a running joke response to any kind of crazy process stuff we were forced to do on my last team. Maybe it works better for small projects/teams, but in my experience it's a massive waste of time.
• bartmcpherson 8y ago
  Why would you let yourself get so stuck in the minutia of SCRUM? Use the parts you need and not the parts that work against you. The value usually listed first in the agile manifesto is "Individuals and interactions over processes and tools".
  • mlthoughts2018 8y ago
    Agreed. It should be about letting a team figure out the highly customized, team-specific things they need to do. If that means getting rid of rigid Scrum frameworks, so be it. Maybe you don’t need regularly scheduled planning meetings, for example, because on a given team the planning might happen in a more 1-1 manner, with irregular and specially scheduled sync meetings that just arise organically from whatever the team’s working on. Maybe you find that estimating story points doesn’t actually correlate with any predictive efficacy for delivery or deadlines, and maybe you find estimating also doesn’t help identify assumptions or potential blockers. So then, just don’t waste time estimating in that particular case. Any part of the workflow, ranging from what project issue tracker you want to use to what meetings you agree to have, should all be adjustable by the team to customize for what makes that team, in that situation, most productive. It doesn’t matter if it’s Waterfall, Agile, Scrum, or just some totally made up, off the cuff meeting arrangement with no formal name and no industry of consultants behind it. Whatever works.
  • Robin_Message 8y ago
    To quote one last bit of minutiae: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." I agree with what you're saying, but Scrum says not to modify it. That's one of my problems with it.
    • srtjstjsj 8y ago
      > implementing only parts of Scrum is possible
• mlthoughts2018 8y ago
  It’s often impossible to talk productively about this because of all the No True Scotsman fallacies uses to defend Scrum, e.g.: “No true Scrum master would do X.” “A product owner who doesn’t Z is just a bad product owner. Not Scrum’s fault.” “If X is disempowering people then X is not Scrum.” These are not valid defenses, and they just distract us from the elephant in the room, which is Scrum’s constant presence everywhere these problems occur. At some point if the tool cannot do its basic job without requiring perfectly scrupulous product managers and “real” Scrum masters, etc., then it’s Scrum’s fault, and we need to think of less prescriptive, less inflexible models that cannot be so easily subverted politically to merely pay lip service to technical quality, while bastardizing reasonable principles to serve quarterly JIRA datamining expeditions and Dilbert-style management practices.
  • mindcrime 8y ago
    Oxygen is also present everywhere these problems occur, so clearly oxygen is at fault...
    • mlthoughts2018 8y ago
      Someone proposes a mechanism by which Scrum is problematic. “In Scrum, product owners ought to empower the team to advocate for technical quality, but in many Scrums, this does not happen, and short-term, quality-ignorant changes to the timeline rule instead.” This is a claim about the mechanism of Scrum’s failure. And in response someone offers a non-falsifiable defense, like, “whenever that occurs, it’s always the company’s pre-existing badness to blame. Never Scrum.” Can you really not see how this is completely different from an unqualified claim that correlation implies causation? Your comment comes off like you think it has some rhetorical punch, but I invite you to reconsider that you migh have completely missed the entire point.
• starbugs 8y ago
  I think the article confuses what Scrum is and what some (probably most) companies make out of it. I agree that there are scary things happening in practice and I've seen a lot of scrumBut and scrumAnd that really endangers a lot of projects. My experience is that this is often caused by a lack of understanding of the methodology and how it can be applied and integrated into existing structures. Also existing structures need to be integrated with Scrum to make it work. That is, they need to be transformed to match agile workflows. The latter is not easy. Especially not in larger companies. I am not surprised that most do not even try to tackle this.
  • Robin_Message 8y ago
    I'm not confused :-) Maybe I don't set it out clearly enough, but I'm criticising Scrum as it is widely practiced, rather than how it ought to be done. And yes, integrating it with the rest of the company is the biggest question, e.g. if you really are agile, what does your sales team tell customers about future upgrades?
• nickelcitymario 8y ago
  Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this. 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line. 3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user. Okay, so that's 3 ideas. It's better than most.
  • walshemj 8y ago
    You also missed the trade off's for increased speed compared to traditional wf projects. One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750
    • nickelcitymario 8y ago
      Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence. Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.
      • walshemj 8y ago
        Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.
        • 8y ago
• brlewis 8y ago
  I disagree that the scrum master needs to be a technical leader. Technical leadership needs to come from the development team. The scrum master mainly needs to be a good communicator, communicating the value of feature priorities to the dev team, and the value of tech priorities to the product team. EDIT: If your scrum master isn't a good communicator, here are some tips for doing the communication yourself: https://medium.com/@brlewis/fighting-technical-debt-in-an-agile-team-c48662abf76e https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...
  • maxxxxx 8y ago
    And the scrum master needs to be empowered to do things. In my company the scrum master has pretty much no authority because the line managers are still pulling the strings.
• JepZ 8y ago
  > Scrum has become the de facto definition of Agile That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states: > Individuals and interactions over processes and tools That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project management methods for decades it is very valuable. But the process shouldn't stop there as Scrum isn't the end, its the start. So companies which managed to implement Scrum should try to move on to more Agile practices to transform their culture over time. [1]: http://agilemanifesto.org http://agilemanifesto.org
  • srtjstjsj 8y ago
    The Scrum process is a set of tools to push individuals into interaction instead of hiding from each other.
    • Clubber 8y ago
      Yes, and sets aside a lot of time for them to interact (read not get things done) for no good reason. I need interaction maybe 5% in my week. Anything outside of that is just goofing off. Oh and email works great for that sort of thing (interaction, not goofing off).
• struppi 8y ago
  If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]). I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong. Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change. But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job. You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start. [1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-true-scotsman-in-agile.html https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t... [2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/ https://ronjeffries.com/articles/018-01ff/hills-to-die-on/ [3] https://www.quickglance.at/agile_antipatterns.html https://www.quickglance.at/agile_antipatterns.html
  • mindcrime 8y ago
    And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change. Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc. Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.
    • Cakez0r 8y ago
• MichaelMoser123 8y ago
  https://age-of-product.com/agile-micromanagement/ https://age-of-product.com/agile-micromanagement/ another interesting observation along this line; when the scrum master is a middle manager then he will micro manage the show - because that's the way he is supposed to function. Empowering the workers is a good idea, but it is not how most organizations work.
  • dasmoth 8y ago
    A slightly different take on why scrum becomes micromanagement, which has always seemed revealing to me: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
    • MichaelMoser123 8y ago
      I don't know about continuous integration; version control + automatic builds really helps to prevent the mess that you have without it. I still remember the nightmare of copying sources from and to a central directory.
      • dasmoth 8y ago
        That’s something I’d probably put on the “good servant but bad master” category. Agree with what you’ve said, but have also seen it start to get oppressive. (One pain point is when it is used to hide build/deployment complexity to the point when it’s no longer practical to build the thing on your own workstation...)
• tootie 8y ago
  Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it". Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective ownership aspect. Product owner gets to set priorities, but it should be a collective discussion. Every dev should be allowed to express their opinion and it's the job of the product manager to referee.
  • addicted 8y ago
    Who is the “you” here? Who is supposed to explain to the product owner that code quality and refractors are worth doing? The real issue the article brings up is that Scrum has an individual who takes ownership and responsibility for the product backlog, it has an individual who takes ownership and responsibility for the project management, but it has no individual who takes ownership and responsibility for the non visible technical aspects of the product. In an ideal world, this responsibility would be taken up by the scrum master, who would have technical expertise, but as the article points out, (a) scrum never states this, and in fact, hints in the opposite direction, and (b) this is rarely the case in the real world. The scrum masters are usually as non-technical as you can get.
    • nradov 8y ago
      The agile team members are supposed to write refactoring user stories and explain their value to the product owner. If the team members aren't doing that then they aren't doing their jobs and need to be trained. Going beyond Scrum, Scaled Agile Framework (SAFe) has some specific guidance on refactoring. https://www.scaledagileframework.com/refactoring/ https://www.scaledagileframework.com/refactoring/
    • jameshart 8y ago
      This is utterly backwards. The team owns it all - the process, the product, the technical artifacts, the code quality. If the team is looking to the PO or the Scrum Master to take responsibility for things, then they are going to fail. The product owner is there to help the team understand what value they can deliver. The scrum master is there to help the team optimize the process. The team hopefully has developers on it who are there to help the team make well engineered pieces of code Maybe there are designers to to help the team make great user experiences. The team has specialists, but the team works collectively to deliver results. If your scrum team has a bunch of engineers on it wondering how to get their voice heard over the product owner, you don’t have a scrum team building your software, you have a PO acting as a tech lead running a waterfall project.
• jarl-ragnar 8y ago
  Scrum is just a simplified process for applying some of the principles behind lean manufacturing to software engineering. One of the core principles of lean is - minimize work in progress (WIP). Sprint's are just a way of minimizing WIP. Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded. A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.
  • specialist 8y ago
    Agile workflow is based on the notion that software can be created thru progressive revelation. Like Moses wandering in the desert. But, as you suggest, per the original writings, the real goal was to better manage upward, and has nothing to do with creating projects. The alternative is what we gray beards call "have a plan". Well, as much as any one can plan for the unknown.
  • blat001 8y ago
    I think that this is a critical point to understand and it highlights why Scrum has been so successful. We know from research in the 80's, and 90's 90% of Software projects failed, due to things like poor estimates or wrong requirements or delays. Agile/Scrum has addressed a significant portion of those concerns by introducing lean processes. This visibility has enabled the business to understands what is happening in the SDLC quickly and can reprioritize and redirect if things are no longer matching expectations. Where Scrum tends to fail (IMHO) is that it doesn't integrate well with other business units. I think the industry needs to focus on release management (predicting outcomes) as a process to help marketing teams, sales teams, etc... if they need to know what is happening in the next quarter, etc... Either that or everyone needs to wait until engineering is finished before talking about new features (sounds a bit like the tail wagging the dog)
• pbadenski 8y ago
  for your daily dose of reflection replace "Scrum" with communism (or capitalism if you like) and developers with citizens
• _pmf_ 8y ago
  Here's a nice situation where the scrum team decided to become self-organizing and fired the manager who forced scrum onto them: https://workplace.stackexchange.com/questions/112596/how-do-i-regain-managerial-control-of-my-self-organizing-team https://workplace.stackexchange.com/questions/112596/how-do-...
• Graham24 8y ago
  There is no silver bullet. Never was, never will be.
• noarchy 8y ago
  One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes those things as a result. Any resemblance to software development methodology has long been lost, if it was ever there at all. That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles. I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.
  • kaustyap 8y ago
    On contrary I found scrum to be empowering for developers at least in my organization. Earlier, we used to have Technical Manager who provided estimate for a feature/project just based on his gut feeling which often was challenging and not feasible. But then developers needed to burn midnight oil to achieve the targeted release date. It often put enormous pressure on highly talented and competitive developers who had to cover up for less skilled developers. Now the development team is empowered to give its own estimation considering all factors. Mind you, in can lead to overestimation, but then we have experienced Technical Lead working also as a scrum master and individual contributor who is there to correct the course. In general scrum will work best when 1. The product owner is from technical background with enormous experience under his belt in product development/architecture. The Product owner does not work alone in silos to create backlog but interacts with development team regularly to refine the backlog. In our case, the product owner is someone with 20+ years of experience who has worked in roles like developer/architect. 2. The scrum master is also highly technical person who has been working on the product for several years. In our team, the same person wears different hats as per the need like scrum master/technical leader/individual contributor. It may not be exactly as per scrum guidelines but worked fine so far for us. Ultimately we need to look for good practices in each methodology and bend it as per our needs.
• himynameisdom 8y ago
  Most of these problems, such as refactoring, lightweight documentation, and tech debt can be mitigated with a good definition of done and a strong understanding of the sprint goal, whatever it may be. This is a classic "Scrum" v.s. "How We Interpret Scrum" hit piece.
• languagehacker 8y ago
  This sounds not so much like a valid argument and more a thinly veiled tirade against one bad project manager this person has had during their career. Yes, most by-the-book approaches to agile project management are bad because they are by their very nature not pragmatic towards the reality of a given engineering team or product organization. No, that doesn't give you an excuse to claim that the tens of thousands of individuals (more?) who have made a successful career out of project management are all incompetent snake oil salesmen because there happens to be a certification with a low barrier to entry. Grow up.
  • Robin_Message 8y ago
    I can see why you'd think that. I just want to put on the record that all of the project managers I've worked with have been extremely competent and a joy to work with. The problem is not the people, it's the methodology that gets in the way of people doing their jobs. The poor implementations of agile that Scrum encourages are what is devaluing project management, not my post.
• jillesvangurp 8y ago
  Pretending to do agile seems to be widespread thing in our industry. There are literally no companies out there not claiming to be agile. So, the word has become meaningless. Scrum is the lowest common denominator in our industry when it comes to that. Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolutionary ladder. Both have issues with not prioritizing essential activities related to research, refactoring, etc. that you need to guard against. There's a difference between agile and firefighting. One worry with scrum is the roles of product manager and scrum master. In my experience these things end up being formal job titles in bigger organizations. This is bad because they are typically on the very low end of the scale. That means you end up with the least experienced people filling these roles and a lot of corporate politics. I've seen more than a few organizations that were hiring accordingly.
  • christophilus 8y ago
    My company doesn't claim to be agile, I don't think. We just allow devs to work on whatever they find interesting. If something really urgent comes up, its urgency is made known to the dev team at large, and someone always steps up to the plate. Works fine for us! Also, we don't have deadlines. Things ship when they are "good enough". Granted, we're very selective in our hiring process, but it means things just work without much need for fancy management practices. If any dev managers are reading this, I can say, this approach works, and you should give it a try.
    • knoq 8y ago
      A previous company I was at worked this way and it was a dream. That said, it does require very selective screening processes and maturity from those you do hire. However, it was the most happy / least stressed I've ever been in my life. I still get beers almost weekly with over half that team. This "strategy" really built comradery because we were always talking and discussing rather than leaving comments on some Jira ticket (which we did for async or when necessary). Seriously.... give it a shot if you can
• gerbilly 8y ago
  From what I could tell, most workplaces use scrums to enforce a minimum starting time for all their developers. They would typically schedule an early in person scrum meeting to defeat all the devs that like to work late or remotely.
  • walshemj 8y ago
    From my experience though using DSDM end of day standups are better. It also helps where team members have different commutes and stops wasting the time of early arrivers. I regularly used to be first in the office even though I had a 70 mile commute to London when compared to my co workers who lived in London.
• mwilliamson 8y ago
  I think the value I get out of Scrum, or XP, or any other methodology, is two-fold. Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team. Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start. I think the key is: 1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change. 2) knowing how each part of your process maps back to one or more of those principles 3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.
  • knoq 8y ago
    Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate why TDD is part of the "agile toolset"? I've seen this claim multiple times and it's never made sense to me. I do TDD on side projects where there's not even a hint of "agile."
    • srtjstjsj 8y ago
      Agile -> YAGNI -> TDD Agile warns against building stuff you don't need. TDD means that test provide the justification for feature work. If your feature work isn't making a failing test past, you don't need that feature work. Obviously this assumes that your tests are justified (ideally there is a stack of tests leading all the way to the end user experiment), but that's much easier to get right than justifying untested feature work.
• jrochkind1 8y ago
  > the product owner often works alone and the development team simply receives a stream of backlog items that need to somehow be brought into a cohesive whole This is the root of the problem in my opinion. I am not interested in defending "Scrum", I don't like what I know about it, in the few experiments I've been involved in with it (not by choice), I agree it was disempowering to developers, trying to treat developers like commodities. However, I am a fan of trying to do things agilely (iteratively, figuring out what to do next in relatively short chunks without trying to plan out the next year+). In the experiences I've had where this _worked_ the product owner was _intimately_ involved with the development team, with lots of communication in both directions, with the development team's info and feedback effecting how the product owner prioritized and determined (and changed, agilely) acceptance criteria. The product owner had to embrace/accept that this would be a significant time and energy commitment to them, they could not be looking to minimize their time here, and had to accept that "with great power comes great responsibility" -- that they needed feedback from developers to make these decisions properly. On the flip side, through these good experiences, I also learned that a good product owner is _so important_ -- as a technical decision-maker I don't _want_ to be responsible for determining product priorities or acceptance criteria. I want my feedback to be taken into account, but having someone else (who is good at it) be _responsible_ for it let's me focus on applying technical excellence to achieve the goals set by the PO, and takes _so_ much pressure and anxiety off of me. Especially when I can trust them to know what they are doing it and do it well (just like they can trust me to execute well). I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".
  • dnomad 8y ago
    A "one way" product owner is useless. Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it might be the most important thing. If developers and all the owners are not continually reviewing the items in the backlog together, clarifying them and making sure everybody understands what is being asked for and what the priorities are, breaking down stories that are too big, making sure that, yes, some tech debt gets in there, then all you've accomplished is a kind of mini-waterfall where stories get shoved to the top of the backlog by whoever comes last and then developers hammer away at them frantically at the beginning of each sprint. > I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing". Scrum consistently fails because everybody thinks in terms of the "who" and the "how." Scrum books are all about the process, the daily meetings, the roles and the responsibility. This a symptom of a much larger issue here, the "technological paradigm" that pervades nearly all corporations. There's an unfailing obsession on organization charts, department boundaries, and processes. It's all kinda silly. As somebody who's managed too many scrum teams to remember here's the secret: don't focus on the "who" or the "how", focus on the "what." The what is all that matters. In Scrum there are certain key artifacts: stories, the backlog, the increment, blockers, and retrospectives. Relentless focus on the quality of these artifacts as documents and you will excel at Scrum. But you have to really care about the quality of these documents. Everybody, not just the scrum master, has to keep iterating over these document/artifacts until they are awesome. This means continually refining stories until people know them inside and out. Continually polishing the backlog until it shines. Making sure everybody understands exactly what will be delivered at the end of a sprint, the increment, and when it's delivered having people write feedback and rate the increment. It means investigating and documenting every single time a developer is blocked for more than 15 minutes and then making sure it never happens again. I've worked with remote/distributed scrum teams and what I've found is that you can even throw out all the ceremony -- the daily stand-ups, the endless sprint review meetings, the endless retrospectives. When the team is distributed between London, Shanghai and Sydney and most of the developers work from home at oddish hours such meetings are impossible. But by focusing on the documents even such a distributed team can fly. So, yeah, at the end of the day this all boils down to effective communication and writing things down. Most knowledge games do. [1] https://www.agilealliance.org/glossary/backlog-grooming/ https://www.agilealliance.org/glossary/backlog-grooming/
• agentultra 8y ago
  What are these technical priorities that are being ignored by your team? I know some examples of cases where the development team was performing poorly which led to a bad experience with scrum. The symptom is when the development team asks for stories to refactor some code. They don't want to add any new value to the system or enable work in a different area: they've just made a rats nest out of the code or it doesn't live up to their expectations or guidelines. The cure for that? Set coding guidelines (and not just the syntax formatting variety: be hard and opinionated on initialization, patterns, and language features), mentor your team to refactor code after they've got it working and made their tests pass, and encourage developers to leave code in a better state than they found it. Also ensure that the business stakeholders and product managers are not setting unrealistic timelines and expectations. In time you'll find fewer requests to create backlog items to refactor code. What else is there though? If your product and team leads are not concerned with security, performance, or other important factors you need to make them aware... that has less to do with scrum and more to do with good communication.
• captainbland 8y ago
  I agree with the criticisms of Scrum on the whole. However I find it bizarre that this article and the other one it links to (which quotes Milton Friedman, which ought to be enough to raise eyebrows by itself) crticises organisations which market themselves as non-hierarchical (or in the marketing lingo 'holacracies') when they clearly adhere to hierarchy if you think about it in any depth, just a badly organised one. Edit: And I guess my real point here is that Scrum doesn't usually work because the development team as a whole has no way of pushing back on decisions made by the overall business hierarchy unless they just go tools-down. Then it goes on to crticise Valve for not delivering HL3, despite that clearly being a successful business (and one where Gabe has over 50% of the $2.5 billion equity valuation... non-hierarchical, sure, whatever you say) - perhaps all of this emphasis on shipping products as fast as possible and no emphasis on the service and the interests of staff is the real problem here.
  • 0xfeba 8y ago
    Yes I thought the jab at Valve was a cheap shot; very poorly supported.
• wpietri 8y ago
  This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all. The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing control hierarchy stays in place. Before, developers built whatever spec landed on their desk. Now they build whatever is in JIRA. Developers in that world can't even conceive of pushing back. It's my belief that if Scrum had had some strong counter-balance to that, like an Engineering Master, then it just wouldn't have been adopted. Scrum won out over the other Agile processes (of which there were several) not because it produced better results, but because it was the one most comfortable for medium- and large-company managers. It provided the feeling of transformation without actually changing anything important. They were doing waterfall before, which became untenable with the rise of the Internet. Now they do mini-waterfall, call it Agile, and imagine themselves kings of the world.
  • ataturk 8y ago
    I don't know... I've come to just resent all of it. Scrum, JIRA (god, how I hate tickets), the whole works. It's a giant dumpster fire at this point. It was never good. Every place I have worked that did waterfall was a mess and every place I have worked that has done agile has been a mess one way or another.
  • maxxxxx 8y ago
    "Instead, the previously existing control hierarchy stays in place." That's what happened at my place. Instead of having only product owners, scrum masters and Dev teams we now have project managers, business analysts, line managers plus product owners, scrum master and Dev team. And all of these roles have some level of authority and want their own personalised reporting. So instead of less management we now have more.
  • fwip 8y ago
    About a year ago, we went from no-process to "agile?? I guess?" And let me tell you, a badly implemented process is a great way to turn self-driven developers into cogs that just do what's in Jira. Getting your tech decisions questioned by non-tech scrum masters during standup, requirements that don't arrive till midsprint, inability to deploy anything that hasn't been specifically inspected by the sole overworked product owner, etc. It's not intellectual laziness, it's a defense mechanism. You can't be emotionally invested in your work if the process makes things worse for everyone, at least not without a good therapist.
• roma1n 8y ago
  Is there a prescribed SW development methodology at large technology companies? (e.g. Google). Google in particular seems to be heavy on tooling but, perhaps intentionally discards SCRUM et al from the outset.
• xivzgrev 8y ago
  I LOL'd at this "Valve is the other famous poster-child of radical freedom. And just as soon as they release Half Life Episode 3, I'll be happy to take lessons from them on getting software delivered."
• it 8y ago
  If there's a Scrum Master, what does that make everyone else involved?
• pigleg 8y ago
  I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc. When trying to explain "Why agile?" to new devs out of school, I struggle "Well... it helps to have been through a soul crushing waterfall deathmarch. If you read the manifesto after that, you will start to weep for joy." But they don't really get it. So i could argue that even when badly done Scrum has improved the success rate and business satisfaction across the industry. Every couple of weeks the business gets some new functionality and the devs get feedback. Great! But I would agree, it's been long enough with Scrum, I'm ready for the next evolution in this story. Much of it does also depend on the type of team, product, environment so that scrumbut customization seems nearly inevitable in my view. Agree we need a way around the short-sighted prioritization, we've overlain some classical PM roadmap concepts to make sure we also chip away at longer term initiatives and debt.
  • Robin_Message 8y ago
    In part one of this series (https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr...) I explain how technical craft was key in all the agile methodologies, except Scrum. So I think that was part of the thinking in the original manifesto, but not expressed at the time (fish don't perceive water?) I suppose you're right that Scrum is better than waterfall deathmarches, but I hope we can do even better.
    • pigleg 8y ago
      You assert that technical craft was key I think by inferring the bent of the associated methodology of each the people involved? I don't agree, I think the main aim of agile was to solve the extreme dysfunction with the business-side and non-technical people, and there it has succeeded. (This is perhaps also reflected in your observation that XP interest has ebbed while scrum continues to climb in popularity.) Have you had a look at the context inthe history statement in the manifesto: http://agilemanifesto.org/history.html http://agilemanifesto.org/history.html Quotes from that: "At the core, I believe Agile Methodologists are really about "mushy" stuff—about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in—and sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff of values and culture." "For example, I think that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations."
• parvenu74 8y ago
  The four points of the Agile Manifesto follow the pattern of “valuing the preferred over the less critical.” Seems to me that a valid — if not infallible — corollary is that if you practice the preferred TO THE EXCLUSION of the less critical you’re guaranteed to accumulate technical debt. The more fastidiously the less critical is ignored the more catastrophic the reckoning will be.
• pjbster 8y ago
  Sometimes - heck, perhaps most times - when Scrum is involved, some organisations are just too fscked to save. Over time, the "leadership" have reacted to market forces by imposing variations on processes, cuts, reorgs and redundancies. The result is a workforce who, even if they were given total autonomy and unlimited resources, would be unable to turn things around. Not that these execs would see it like that. Instead, they hear this Scrum thing has worked wonders elsewhere so they wheel it in and, if it fails this time, it's clearly the crappy workers who are to blame. "Management was right about that all along." I take other commenters' point about strong leadership making a difference. Fully agree with that. But some situations are simply unrecoverable no matter how great the team.
• deleted 8y ago
  [deleted]
• rhacker 8y ago
  We got rid of most processes. I "think" what we do now is Kanban - I say "think" because I haven't looked at Kanban closely really. But we look at our board, and everyone just works on things, and when they are done, we help assign a new task. When code is done, we roll to QA, when that is done we merge, and release to production. Issues that get worked on are usually in production in a couple days. This excludes major refactoring work or risky items. Those are handled in special unique ways.
• ChicagoDave 8y ago
  As long as tech debt stories are created and prioritized and poc’s are enabled through stories, Scrum works just fine.
• heartteams 8y ago
  I've had a lot of success working with teams that use scrum practices and agile values. Many team members (like several developers and testers) have actually gone on to become scrum masters themselves at different companies. The feedback I've gotten is that it's an empowering way to work - you choose your commitments, team aligns around a goal, priorities stop constantly changing, teams make time to improve the things that slow them down, etc. It's hard for people to go back once they've seen it work. The people that I've worked with have said that when they do move on to other companies they didn't realize how helpful it was until it was gone. It can seem like some bullshit, I get it. It's change. It's not a perfect model. Also, when leaders or teammates behave in a command-and-control and uncollaborative way, it's a lot less fun. Biggest personal challenges: connecting team members to real clients, integrating UX (need more people and up-leveling of team members), too-stable of teams (I like forming around new ideas and the excitement of that), being distributed, the language (Scrum Master - really?!!?), perscriptive agile peers
• FrankyHollywood 8y ago
  Dave has an interesting talk about it. https://m.youtube.com/watch?v=a-BOSpxYJ9M https://m.youtube.com/watch?v=a-BOSpxYJ9M My personal experience is any project where scrum actually works is a boring project, no interesting problem is predictable. Fortunately I see mostly frustrated scrum masters, not understanding why planning fails :)
• axilmar 8y ago
  The problem with Scrum is that it tries to solve one problem (the problem being that business processes are dynamic in nature) with a set of tools that is not meant for this kind of development (namely, static processes, static development procedures, static tools). The actual solution to business needs is to able to create software like a clay sculpture. I.e. build the software in front of the client, using dynamic tools, satisfying their immediate needs. There is no need for sprints, retrospectives, and all the jazz, if we could actually create our software as dynamically as business processes are.
• pbadenski 8y ago
  Milton Friedman famously said that “one of the great mistakes is to judge policies and programs by their intentions rather than their results.”
• deleted 8y ago
  [deleted]
• emilesilvis 8y ago
  Let's do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework. As the author states, "So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities." Let's add another role to scrum called the craft master. This individual has excellent technical leadership skills and deep technical knowledge. The craft master's goal is to defend what the team is doing as a craft (much as the scrum master would defend the process of scrum itself), making sure that the craft's level of quality is manifested through a Definition of Done that takes way more of a center stage than it currently does. Would this be empowering developers? IMHO, the answer to this question is "yes".
  • steveropa 8y ago
    I am on the fence. A master craftsman is awesome to have on a team, but I worry that, just as understanding of Scrum gets pushed off as the Scrum Master's problem, craftsmanship would become the craft master's problem. That's how we get "team leads" and "architects"
• matt_f 8y ago
  Hey folks. Short question: What's better? I read through a lot of detailed analysis of Scrum's shortcomings in the comments here, but little in the way of "Instead". If anyone cares to share his/her vision: based on your experience, what would be a (nutshell) model for a better system? Thanks <3
• ericjwhuang 8y ago
  Robin, most of what you mentioned in your article are true and I agree with them. I had very similar situations (conversatons may end up with "alright, this is Product Owner’s call") and I understand most of developers get frustrated about this. I had been there and I was the developer who got frustrated, but I managed to change it (yep I also agree Scrum does not teach us how and we had to figure it out ourselves) by understanding PO, influencing them about what we proposed by describing value and making a plan for win-win. It is not a fun journey to be honest, but once you are there (we are not completely there yet) your team will trust each other and work more collaboratively. I am really happy to know I am not alone and I have so much to say and share, if you are interested in it, saw my experience at https://medium.com/@ericjwhuang/how-scrum-fails-and-what-you-can-help-b3073f587537 https://medium.com/@ericjwhuang/how-scrum-fails-and-what-you...