Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
What does "running the project" mean here?
The person who "owns" the project. Generally they run it, as it's their ass in the fire.
Agile projects need a Product Owner (and that's usually where projects diverge the most from the ideal - I've never met a PM who actually attended scrums), to stack rank work and answer team questions about requirements.
I don't believe I've been on an agile project where PMs did not run the scrums. Most because they thought they should, and 1 that actually ran the project like I would have. That project succeeded by the measures stated when I joined, but failed by the original measures. I'm not sure I'd call that project Agile nor SCRUM, but more like a development sweatshop, unless that's what successful Agile devolves to. All the other PM run projects failed, due to missed deadlines, missing functionality, and/or cost overruns. I have missed on occasion in projects where I was responsible, as has everyone, but never by more than 20% on time and I've always delivered everything in the original requirements. (see below)
...One point of Agile is that the scope falls off, rather than the date slipping, but that's not all that different from tradition.
I always agree to a core scope that must be met, and then the nice to haves that are negotiable. This approach leads me to a much better success rate, happier clients, and successful projects. The agile approach has left disaster and/or disappointment everywhere I've seen it. Because the world is promised, and only some is delivered, on "successful" projects. Success does not mean delivering everything on time and within budget. You at an optimistic best get 2 of those 3 with Agile.
No, in fact, that's not what he said - he said Agile says "you don't need a plan."
I did not, in fact, state that at all. What I said is "One of the many failings of Agile is that no where does it really say anything meaningful" and "Because no where does Agile say that mini-projects are part of the process"
I said "Agile says 'plan in small increments, and revisit your plan to refactor and rework it constantly.'" What part of "keep the top priority things up to date, clear, and well-estimated," says "don't plan anything!" to you? Because in my world, estimating, clarifying, and 'scheduling things for inclusion in upcoming sprints' is EXACTLY what constitutes "making a plan."
Perhaps because I deal with projects that cover 100s of developers with budgets in the millions? And a business doesn't want to know in 8 or 16 weeks that their budget is going to be run over by 200%, or their timeline is going to be double? Ie, before committing to rewriting, lets say, an airline reservation or large shipping logistics system as examples, they'd like some realistic idea of the cost and time involved. Agile as the "manifesto" and in practice is incredibly inept at doing what I consider real work. It may work fine for small projects and teams, but that doesn't legitimize it any more than a working car made of paper mache is ready for 150mph on the autobahn.
So, you have no plan other than for a few weeks, and you are just sitting down and banging code out since "there's very little point or value in trying"...
No, you unmitigated buffoon,
That's pretty much exactly what you said, and now having been called out on it, you're resorting to name-calling. About as well thought out as the manifesto....
you have a rolling window of "several weeks to months of planned work," for the lifecycle of your project. You engage in planning THROUGHOUT the project life cycle, you don't just say "We'll plan the first 2 weeks, and then wing it from there."
And yet that is wholly the same thing as winging it for the scope of what I'm discussing. 2 weeks, 2 months, whatever your window is, is irrelevant. I don't need to know 12 months in that the costs are going to double, or the time line is going to be missed by even 1 month, or that I'm going to have to cut half my features, which basically means I miss delivery. This is the real world, and people don't like driving cars with 2 wheels and no seats, or flying in a plane with no windows. If you still don't get it, you're a... well, you ask it yourself, so, wear the badge with pride.
Anybody who is still able to pretend that this is what Agile teaches in 2015 is a fucking moron. Are you a fucking moron? You might just be.
I design and build a data store, complete with an API in between. (the Foundation) It was designed with certain requirements in mind, because performance is a key metric I'm going to be measured on when it's done. Some Agile moron comes along 6 months later, and decides that he needs to filter with permissions in a new way that the DB was not designed for which works with today's traffic. Ideally this change requires a new foundation, because now, instead of an arch bridge, we're building a suspension bridge. The foundation requirements changed, and if we were doing it right, we'd tear everything down, but in the agile world we just slap some extra code (mortar) on the foundation, and voila, it runs/stands. Then traffic doubles, and the bridge fails.
You will pay the piper, sooner or later. Agile advocates later, which is why it's so popular with business types. That's fine if you never plan on being anywhere longer than a year or two, and don't really care what happens after that.
My last 2 sentences are how I run projects. It's not Agile in any way, although Agile did claim some of those features as its own, eventually. Do recall Agile, when it started, promoted XP, essentially code for how to take 2 developers and quarter their output. It's gone through several redefinitions since then, and just because it touts some ideas I've been following for years prior to Agile's conception doesn't mean those ideas are "Agile".
That's not quite Agile - you need enough of a plan and a design to know WTF you're doing before you start, you just don't need an in-depth design of stuff you won't even touch for 6 months. But you know what the components are, and about how big each one will be, at least relative to each other, and you know where the dependencies are.
What you're describing is not listed in the Agile manifesto, and certainly not in the first few years of Agile crap. This is progressive project planning, and it existed decades prior to the Agile plague.
So how do you know ho long it will take? You measure you're progress! When you know you're 20% done, and it took a month, then you know it's a 5-month project.
That's utter crap, and you know it if you're any good at all. You have no way to measure it that accurately unless you're doing cookie-cutter code where the next 10% of features are just as hard as the previous 10%.
I've been within 5% on estimates for large projects, even as they changed significantly over the course of the project we could be that accurate on updated estimates.
Why weren't you 100% on target? After all, you updated estimates as you went. The better question is how close were you to the original estimate with allowances for the major changes along the way? I've been within 10% on a number of projects I was in control of. With a specific Agile project being run by a PM, a BA, and 2 stake holders we were about 500% off. Notice a problem there? Not a single technical person. Because Agile told them you didn't need a technical person running the project, and that costs would be contained, because, well, they were using Agile. They even had their Agile certificates hanging on the wall.
Agile is intended to get you to stop trying to jam a square peg in a round hole. The alternative is to pound on that bitch 'till it's round. Which one is likely to result in a better engineered end product?
If I need a round peg....
Agile does NOT say "start coding and figure it out as we go." Agile says "Take some small subset of the functionality you've declared "the most important," estimate that, and deliver that."
So your version of Agile is create mini projects? Because no where does Agile say that mini-projects are part of the process. (One of the many failings of Agile is that no where does it really say anything meaningful) What you're describing is project planning, not Agile.
If you're a true Agile team, you're cross-functional, which means that proper representation from ALL of the organizations needed to deliver the product is present, embedded in your team.
Um, no, this only happens in organizations that are small enough that everyone's involved in 1 project. In the real world, I may have 100+ people working on a large project. There's no way everyone involved with all aspects are part of all teams. All they'd do all day is meetings, which, btw, is another one of the major failings of Agile, it leads to meeting paralysis.
While devs are banging out designs and code, Testers are working on test plans and test automation given the specs that the devs produce, and Support people are building operations documentation and support matrices etc. - all in parallel, all coordinating with one another as the process goes.
That's a nice fairy tale.
0) It's hard to explain to people that they need encryption, how it works, what it is. People think email is secure! The "envelope" iconography is very misleading - email is more like a postcard, delivered by a random selection of disreputable postmen.
This is incorrect at this point, I'd say it's more like a postcard pinned to a bulletin board in the hallway, with everyone passing being required to take whatever cards are going to where they are going, with the requirement that multiple copies be made and dropped at every corner on the trek. That's probably more accurate as an analogy of today's email situation. The implication being, obviously, that email is visible to everyone on the trip, and copies are made and kept.
As for the rest, there are ways around a lot of that, but we're not there yet. Your analysis of webmail is spot on, webmail as it lives today should die a very very quick death. The sooner, the better.