4 ms·

Just a quick rant about SCRUM: I have found that SCRUM is used to allow everyone in the company to believe that the development team is at maximum productivity

Just a quick rant about SCRUM: I have found that SCRUM is used to allow everyone in the company to believe that the development team is at maximum productivity. It encourages conservative estimation, low-ambition projects, and generally business-friendly, highly measurable pace (with metrics that don't really matter but sound good). If you have to resort to SCRUM, your company is probably already toxic (or else the last company your VP of Engineering worked at was toxic). When you don't have good product/market fit, everything the development team builds looks like a miss (because it is) even if the technology works very well. Thus, good product management is crucial. In the greater scheme of things it matters very little if every single features ships two months late. The most important thing is that the product gets closer and closer to the product/market fit bullseye. SCRUM insulates developers from managers who would constantly change their mind and thrash the team around willy nilly, but it also insulates developers from the realities of the business. With good product management, everyone buys into the challenge of product market fit, and everyone wants to apply the right blend of qualitative and quantitative approaches to build the right thing at the right time. SCRUM is fine if everyone is already cynical and there is widespread mistrust, but if you want real team cohesion it's a bad idea.

fat0wl 11y ago
I'd like to at least offer some support to this -- I'm not sure I agree with all of your conclusions but since switching to Scrum mentality I definitely notice that the goals of our team have become much less ambitious... Rather than insulating for development cycles that may not yield much for a few of months but in the end equals proper enterprise architecture, the business/devs have found it much easier to focus on small iterative tasks that are much more superficial in the grand scheme of things. I think engineering processes benefit when they are insulated from direct scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile seems to be a sign that there is a lack of technical leadership/vision. This is not necessarily the fault of Agile (I don't mind Agile, I think projects can succeed with it if approached properly), I simply agree that increasing process rigor seems to be a symptom of an engineering/mgmt team that is floundering. In short, if your team's problem is that things are getting "messy" and "hectic" because of too much crappy copy/paste code, I have seen how Agile can just deepen that wound while masking it in a veil of "tangible progress" seen in burndown charts. Then, again, if you don't have the right people you don't have the right people. What else can you say?
- joshdotsmith 11y ago
  I'm guessing if you're the kind of manager that sees progress in burndown charts you're already on the wrong course as it is.
joshdotsmith 11y ago
This is precisely my concern when servicing clients. Have you (or has anyone else) worked as a client-facing development team and successfully dealt with this tension? Obviously in the case of great clients this becomes a non-issue, but when clients are new to product development, do you simply need to have a very strong hand to make the product successful?
mr_luc 11y ago
I'm not sure if your comment will get much attention because of how strongly worded some of it is, but I feel it contains a nice insight about the relation (and potential tension) between Product and Process. If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work! The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions. One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with. ... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).
bandrami 11y ago
Bingo. Scrum works for products that have already been sold but not yet implemented. That is, client work.

fat0wl 11y ago

I'd like to at least offer some support to this -- I'm not sure I agree with all of your conclusions but since switching to Scrum mentality I definitely notice that the goals of our team have become much less ambitious... Rather than insulating for development cycles that may not yield much for a few of months but in the end equals proper enterprise architecture, the business/devs have found it much easier to focus on small iterative tasks that are much more superficial in the grand scheme of things. I think engineering processes benefit when they are insulated from direct scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile seems to be a sign that there is a lack of technical leadership/vision. This is not necessarily the fault of Agile (I don't mind Agile, I think projects can succeed with it if approached properly), I simply agree that increasing process rigor seems to be a symptom of an engineering/mgmt team that is floundering. In short, if your team's problem is that things are getting "messy" and "hectic" because of too much crappy copy/paste code, I have seen how Agile can just deepen that wound while masking it in a veil of "tangible progress" seen in burndown charts. Then, again, if you don't have the right people you don't have the right people. What else can you say?

joshdotsmith 11y ago
I'm guessing if you're the kind of manager that sees progress in burndown charts you're already on the wrong course as it is.

joshdotsmith 11y ago

This is precisely my concern when servicing clients. Have you (or has anyone else) worked as a client-facing development team and successfully dealt with this tension? Obviously in the case of great clients this becomes a non-issue, but when clients are new to product development, do you simply need to have a very strong hand to make the product successful?

mr_luc 11y ago

I'm not sure if your comment will get much attention because of how strongly worded some of it is, but I feel it contains a nice insight about the relation (and potential tension) between Product and Process. If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work! The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions. One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with. ... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).

bandrami 11y ago

Bingo. Scrum works for products that have already been sold but not yet implemented. That is, client work.