Tumblr Has Lost Almost a Quarter of Its Value Under Yahoo’s Ownership
buzzfeed.com
buzzfeed.com
The title leaves the impression that the way Yahoo has managed Tumblr has harmed the site. It may have, but the article presents no evidence to back that argument up.
"Yahoo writes down 230 million dollars on Tumblr".
Can you explain the mechanics? A write-down will be reflected on YHOO's accounting statements and will lower their tax base.
If IRS allows a company to record (and carry forward) such a loss without corresponding intrinsic value loss, that seems like a pretty large loophole.
This is buzzfeed.
Either it lost value, or Yahoo overpaid. Both can't be true at the same time. Make up your mind, buzzfeed. Was Tumblr worth $1.1 billion and has now declined, or did Yahoo overpay?
Of course, value is relative and only based on what anyone will pay for it.
This has everything to do with Yahoo messing with its balance sheet and manufacturing an earnings number and very little to do with the value of an independent Tumblr.
Of course there are confounding factors. Maybe Agile/Scrum are working well in Tumblr but other things are keeping them from achieving their higher value. Or, maybe Agile/Scrum bleed away productivity and fail to extract value from engineers. Or maybe it's a mixture.
In either case it seems useful to point it out, ask questions about it, and so on. We shouldn't let Agile-adhering failures go un-called-out, whatever the post-mortem analyses might bring.
Agile, when implemented and executed correctly, really just shortens delivery cycles and allow for small corrective changes along the development path. What it's best at is delivering a product that more closely aligns with needs, than something like Waterfall.
In many cases the overall delivery time might be longer with agile, but the correctness of the project is better. Which means less QA at the end of the cycle, and more throughout the entire process.
I also see a lot of this No True Scotsman fallacy of saying "when implemented correctly" that Agile, seemingly by definition, cannot fail.
The teams I've seen be most effective at delivering quality products quickly always just created their own methodologies, and they would scrap them and change them often particularly based on changing needs of the project, new personnel, and so forth.
Instead of the Agile approach of trying to say there is a one-size-fits-all / cookie-cutter solution (e.g. just use this timeframe for every sprint, just use this way of dividing up work for every project, just use this way of measuring progress for every team, ...), productive teams seem to negotiate this stuff organically, and with common sense.
Even teams that nominally used Agile but still managed to be productive did so precisely by only adhering to Agile as a ritual to appease managers, and outside of what managers wanted to see, the teams just eschewed Agile and found ways to be productive in spite of it. That may not be true everywhere, but it informs my experience in three different Agile organizations of varying sizes and ages.
Where agile is defined as what?
Any vague attempt to do that, even with customization and variation within a given company, has always resulted in the same unplanned mess of randomized sprints and burndown graphs.
Poor choice of words, you are correct. And I actually agree with what you're saying in the rest of that response. Allowing scrum teams the ability to decide how to work together is huge, and I think correct as you point out some of the benefits of that. Rigid inflexible systems are horrible.
One thing that I know puts me generally in conflict with most agile purists is that a sprint should only have a time estimate component, and not a firm end date. Shoot for two weeks,but if it's three so be it.
Agile is great in small, well-controlled cases where the path to a solution is easily seen by everyone to consist of commoditized, been-done-a-million-times-before tasks. But the issue is that once you use the Agile hammer, now everything looks like a we-must-solve-it-in-only-the-been-done-a-million-times-before-and-fits-into-sprints nail.
The other big thing is that so, so few Agile implementations are remotely like the Agile ideal that we should probably stop pretending there even is an Agile ideal. If everyone using a given tool consistently messes it up in the same ways, we should just stop trying to defend the tool and admit it's the tool's fault for being intrinsically easy to misuse/abuse, and seek to invent better tools that make it very hard to misuse/abuse them.
If you break it down, you probably already do this: 1) get build for project going, 2) get initial config/entrypoint for system up, 3) implement stubs for API, etc... you can break it down, but each of those is a constrained set of work. It might be part of a very large project that can't "ship" at the end of two weeks, but you can verify different components along the way. It also is a helpful exercise to allow for multiple people to collaborate on different portions of the problem.
The portions of the app that were very "customer facing" were exactly as you describe -- things like the user interface, APIs for educators who made use of the tool, etc.
But the statistical modeling and "science" code at the core of it was completely different. You could not propose a series of step-wise changes that could be pre-planned over short-term horizons. You might propose something and after 12 days of working you might discover it was mathematically not going to work, regardless of engineering effort, and you could not have foreseen this (or at least our experienced team of stats people could not).
If you say something like "solve this hard cryptography problem" or "find a way to forecast X with Y% accuracy" or "determine an architecture that will boost performance by Z%" -- these questions are hilariously ill-suited to someone just pre-specifying a set of steps for a 2-week period. There's nothing magical about 2-weeks that implies you can always make meaningful progress on every problem in that time frame. Sometimes you can't, and the extra constraints of trying to pretend like you can and structure work like you can act as significant hindrances to the real processes of discovery underneath.
I agree this is somewhat rarer than the types of work that do fit neatly into 2-week chunks. But a lot of Agile evangelists want to politically recast the engineering efforts as if it's always that way, and that any request for more of a research approach to a problem must just be coming from whiny engineers who don't want to deal with real-world deadlines. And, predictably, this leads people to try to solve totally non-Agile-suited problems in rigid Agile-only ways, which ends up bad for everyone.
This is perfect though! In two weeks, you discovered the wrong thing. That's as valuable, IMO, as finding the right thing. The goal I find in my work is to try and fail fast... in other words, discover as quickly as possible whether or not a particular solution is feasible or not.
For truly complex issues, I have found that it often can take upwards of three failures before you discover the 'right' way to solve complex problems. You might have worked in an environment that didn't allow for failure and/or changing of dates. That definitely sucks.
Maybe I didn't describe it very well. 12 days was perhaps a poor choice because it is convenient to a sprint cycle, but in my comment it was meant to function as a random placeholder.
This type of work happens like Poisson shocks, or like lightning strikes. You work and work and it seems like you don't get a single thing done, zero story points completed, etc., and then boom, in one fell swoop you figure out a huge advancement in the problem. That's the defining aspect of the work I am talking about. The burndown graphs will look like (and should look like) a flat line that suddenly drops to zero near the end.
It has nothing to do with "failing fast" because it's not "failing." It is the process of discovering what the actual problem is. This is very different than a situation where you, say, try out a MVC architecture but later realize it's not optimal for a business use case and need to change it to MVVM or something. You can always make measured progress on the first attempt, and if it doesn't work, that would constitute valuable failure-case knowledge.
But with more abstract questions it's more like you are saying this: we tried to solve it, and we are not even sure whether or not we've made any progress yet, and we won't be sure until right at the moment we've either solved the problem completely or demonstrated why our whole approach cannot be used to solve it.
That's perhaps a very idealized version; most problems don't fall that far on the research spectrum. But the point is that many problems still do fall pretty far on that spectrum, and if you set up your approach to them based on doing Step A then doing Step B then reporting about metric C, etc., it actually hinders your ability to solve it, since the very nature of the problem is not amenable to that sort of thing.
But I do think that you are tending to blame agile for what really sounds like poor management. Management wants to see what progress is being made, so they use burndown graphs. Development, as you point out goes through spurts, except for the most basic tasks. So to management it can look like there is no progress being made.
What I'm trying to point out is that trying to divide the problems into as small of a set of isolated components as possible may help get to a solution. But that doesn't say your wrong. It might take months of time to find that solution, the problem is you need to explain to someone over that time what you're doing, otherwise the money and project will be cut. This is where it can be good to try things out and show what you've learned over that time, this is important for managing up.
Basically, what I'm looking for in an engineering process is one that raises engineering concerns above manager and executive political concerns. In any organization you always have a struggle over who gets to use the phrase "business priority" -- do engineers get to say that the engineering work is the priority, or do managers get to say that political circumstances are the priority? Agile makes it easier for managers to promote political concerns while at the same time acting and talking as if they promote engineering concerns more. I'm perfectly happy being shown real business evidence about the cases when the engineering concerns are not primary -- but Agile offers ways for managers to never provide such evidence, to keep people busy generating more and more progress metrics that give them more political surface area with which to manipulate.
I guess you could say this is just "poor management" but then I think we'd have to agree that 99.9%+ of management is "poor management" because this all repeats itself constantly in organizations of all ages, sizes, and stripes. And Agile is a hallmark indicator of such a dysfunctional engineering culture.
For me Agile is the least bad solution, it's definitely not ideal, and it's a million times better than Waterfall.
> agree that 99.9%+ of management is "poor management"
I'm not sure about the percentage, but good managers are rare.
Just because you're iterating on 2 week cycles it doesn't mean there's no vision, direction, or planning on a longer time scale. The "backlog" user stories have to come from somewhere, right?