Comment by DanielBMarkham | Hacker News Reader

Comment by DanielBMarkham | Hacker News Reader

I love collecting these rants. For a long time, I've been convinced that various techniques may be fine and dandy, but the way we implement change in organizations sucks.

Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't care less about brand names and religious dogma. I'm a developer first. If it works, do it.

Having said that, this author does not know what he is talking about. Apologies for being so blunt, but there it is. And he probably doesn't know what he's talking about because his organization has failed at making changes.

Really there's just a couple of questions to ask yourself. Can you get everybody important to the project into the room working together? Can you guess what you might do over the next week or two?

If you can do those things, hell if I care what you call it. If, however, you believe that complex systems must always consist of dozens of people with various deep-dive specialties? Then we've got a problem.

The problem isn't that some things in life are tough. Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others.

In some cases, the business environment means you can't have everybody in the same room. Fine, there are strategies for that (too much to go into here). In some cases, people just want to keep working the way they've always worked. Most of the time it's the latter case, not the former.

It's a shame that this person's environment has failed them in this way. No, Scrum is not made for a lot of things, but you are not a special snowflake. I can freaking guarantee you that no matter what technology problem you're solving, all that Scrum/Lean/Kanban/yadda yadda stuff has been used to help folks run fast. I would suggest trying to find other teams doing the same thing you are, only much faster, and watching what they do. That's how all these buzzwords came about, anyway. If you don't want to believe the books and trainers, and I'm fine with that, go watch it work. Then write another article. :)

> It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others.

I think you're wrong. What you should realize that there are many enemies of productivity, and different for different people.

For instance, for me, having useless meetings (like standups or groomings) is mentally exhausting, and it kills a lot of motivation for the day.

I was most productive under well managed waterfall - where we had one longer status meeting each week, and instead of grooming interrupting work on the problem every week or so, we had time to think about the problem complexity at the beginning of the project.

In my view, the key to productivity in programming is focus. Whether you focus as a team or as a person doesn't matter. What is needed though is someone reliable who can shield you from all the distractions, and can do that without actually distracting you. In my experience with SCRUM, all the distractions are dumped onto developers (all of them in fact, via standup).

I am not against Agile development (in particular, just like author, I am not against iterative development or Agile manifesto), but the SCRUM I found rather silly. It's an attempt to do one-size fits all.

Not every feature requires exactly the number of people in the team. Not every feature requires one sprint of time. Some require less, some require more. If your work is managed correctly, you don't have worry about these arbitrary boundaries (which will always exist because time-boxing and standups, no matter how long the sprint or how big the team, are the key features of SCRUM).

For me it is exactly the other way around. I hated those weekly 3hr status meetings. Sometimes, I fell asleep. And I hated that all the specifications had to be upfront, without flexibility for the team or the stakeholder. Nothing was more counterproductive than implementing a solution, that when I knew half-way in that it was flawed.

With Scrum, if something bugs me, I bring it up. We do standups only if required (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.

Well, if my math is correct, 15 minute meeting every day still beats 3hr status meeting every week. Our status meeting was only about 0.5-1hr long, and we actually got a bit more done, because you're not supposed to go into detail during the standup.

Anyway, what you seem to praise is Agile (as per the manifesto), not SCRUM, and I agree (although some problems are actually suitable for upfront specification). Still, distractions can be a problem on the other extreme that needs to be managed too.

That assumes a 15 minute meeting only steals 15 minutes from your day. It's usually closer to an hour once you factor in the work-free buffer zones surrounding it. (Cf http://www.paulgraham.com/makersschedule.html)

This is an interesting remark:

"Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others."

What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties?

Some sprints might be heavy duty on a specific area of specialties, how can Scrum balance the productivity within a team?

A good friend of mine exclusively helps embedded teams. I just got through doing cloud with some folks. Big data is its own thing, but certainly not a show stopper.

If you're serious, email me. Happy to explain to any depth you find adequate.

>What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties?

Then maybe Scrum isn't the best approach. Scrum (and agile methodologies more generally) are not designed to solve cutting-edge problems where it isn't even clear whether the product is possible, much less feasible, to build. Scrum is designed for software teams working in a well-known problem space (e.g. line-of-business web applications) where the challenges are organizational (getting a clear set of requirements and managing requirements churn) rather than technical.

I certainly wouldn't expect a scrum team to deliver software for a brand new problem domain. For something like that, I'd expect better results from something like spiral, which explicitly includes room for research, experimentation and prototyping at each stage.

Why can research and prototyping not happen in Scrum? I don't see any limitation.

The problem is that research and prototyping is difficult to estimate even when you have a history of estimates. The advantages of scrum really kick in around sprint #4 or 5, when your team has a history of estimates that you can refer to when you're estimating future work items.

In a research setting, this breaks down because the work for sprint N is totally different than the work for sprint N-1, which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.

> which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.

But you're not supposed to do that anyway. Story points are always relative, so your tasks (in sprint) are relative to one another.

We always "effortbox" our research tasks into a set number of story points.

If you cannot estimate something, then you should do it in a timebox over and over again, until you are satisfied. If my project requires lots of research and prototyping, I still have valid and useful options in Scrum.

For research, my team will have short sprints with timeboxed backlog items. The result of a research item can be a presentation of the discoveries and a vote / discussion on what to research next (sprint review). If my team's research isn't done within that timebox, the findings are presented anyway and the team / stakeholder may decide to simply file a new backlog item on the same topic for the next sprint. Or the incomplete result is a sign of complexity which can be split into many backlog items. Such items can be that the team decided to get external consultancy or a product presentation by a vendor.

If the team has to mix research with prototyping, it could do two types of sprints: short research sprints as explained above and longer implementation sprints for the prototype that are based on the research results. For example, the team may require two, one week sprints for doing research and then a two week sprint for implementing or continuing a prototype. At the end of each sprint (sprint review) there is a decision on whether the next sprint will be a research or a prototyping one.

So Scrum is still a valid method that enables a team to even steer research and prototyping efforts. This is where Scrum actually shines, because it gives you flexibility and transparency (!) in an uncertain environment.

That actually sounds like a really neat process and I'm glad it works for you. One question I have is about how you measure velocity with variable length sprints. My understanding of scrum is that the point of having fixed length sprints is that it lets you easily estimate how much you can deliver in a sprint, since each sprint is the same length.

If you have different length research and implementation sprints, how would you estimate the amount of work (whether in story points or whatever else) that can be done in a given sprint? Is it a matter of making sure to compare "like to like"?

"Scrum is designed for software teams working in a well-known problem space"

More narrowly, it's for problems which can be broken down into more or less independent "features". It's not too helpful if you're building something which doesn't do anything useful until all the parts are working. The Scrum mindset is to first build a flashlight app, then add features.

(If only that were a joke.)

    Flashlight app with an EULA, a privacy policy, and ads.[1]
    Flashlight app with in-app purchases.[2]
    Flashlight app with spyware.[3]

[1] https://play.google.com/store/apps/details?id=goldenshoreste...

[2]https://itunes.apple.com/us/app/light-led-flashlight/id37975...

[2]http://www.komando.com/apps/3112/turn-your-phone-into-a-flas...

> Scrum is designed for software teams working in a well-known problem space

I always have to wonder, if your problem was already solved, why don't you just buy off-the-shelf solution? If you aren't doing anything new, what is the point? It seems like you cannot organize the work correctly already! Frankly, if you have failed to use what was already done, no amount of management methods will help cover _that_ productivity screw up. :-)

Well known != well solved. It's the difference between "we need to build a web application to do X" and "we're going to redefine how people do X".

Secondly have you seen Salesforce? The COTS solution isn't zero configuration in many cases. Plus many businesses decide their unique selling point can be having bespoke software that has a feature that the COTS version can't do, or do as well.

I've just spent 3 years using SCRUM to build a CRM system after my employer decided not to go with Salesforce because they wanted everything to match up to how we do things. Plenty of other firms in our industry are extremely jealous of what we've produced because it is domain specific rather than over generalised.

As a note, Scrum started outside of software development. It was created to deal with brand new problem domains with many unknowns.

Reply on news.ycombinator.com