My company converted to scrum 4 years ago, after pretending to be “agile” for 5 years and not really being very agile. We follow a fairly typical scrum pattern involving: 2 week sprints, a “self-organizing” team, a constantly evolving backlog, daily standups, and a smattering of standard scrum meetings during each sprint.
I’m not sold on the 2-week sprint idea, and I think the self-organizing team is never really self-organizing. I do like the meeting structure. But to me, the biggest improvement over our previous methodology is the backlog – and not really the backlog itself, but convincing everyone involved in our project that what they thought they wanted wasn’t really what they wanted.
Prior to the backlog we were either given or had to produce a formal requirements document (SRS) for each iteration of development. Our customers liked this because they knew what they were going to be paying for. Management liked it because they knew exactly how long something was going to take (hah). When we did change requests, were supposed to go back and update the SRS so that would could always hand it over to another company to have them build the exact same thing in the exact same way (hah). In practice it never worked, we’d spend months developing something that would never get used because the customer didn’t know what they wanted originally, or we’d catch issues way late in the game and have to do a ton of refactoring, etc. So to me the big advantage was to say, “You don’t want this. Software moves too fast and you’ll never get the requirements right the first time. Let us just start developing and trust that we’ll do what you want in a reasonable timeline, and we’ll show you where we’re at and you can make adjustments along the way. And when we’re done the product is the requirements specification, nobody is going to want to look at our description of it, they’re just going to want to see it.” It’s been an interesting experiment.
Recently my wife (a CPA, not at all software oriented) came home and said that her company is pushing scrum across all disciplines. Her accounting team does daily standups. I’m not sure what else they do that’s scrummish but I’m curious to know if other disciplines have successfully adopted any of the components of scrum.
We’re a programming shop and have been using a scrum variant for a few years now. We use a two week sprint, but don’t pretend that we’re going to finish everything in the two weeks; it’s more something we arrange our meetings around. The mere fact that Scrum forces the company to prioritize things explicitly and that its tools help everyone keep an eye on how things in progress are developing has paid for itself ten times over.
I hear that other some departments are doing the daily standup, but I don’t get the impression that they’re doing the task organization stuff; it probably wouldn’t make much sense for types like sales and support.
After doing scrum for just over a year, I don’t think it has made our development faster, but it certainly has helped the delivered product quality, and transparency among and between the development team and the business.
I can’t speak to “scrum” in particular, but I’ve spent enough time in corporate environments that I’ve seen these kinds of things come and go with some regularity.
There’s always some new trendy operating philosophy with its own set of strategies and buzzwords and highly paid consultants. (Remember Six Sigma? Is that still a thing?) I’ve developed a healthy cynicism around all of it.
In the end, if you have competent management and a decent workforce, things will get done. Everything else is just noise.
In the development teams I’ve seen using Scrum or Agile, they always end up with “We’ll add security later” and then don’t. How have the posters here seen security added into the project?
We put a task in our tracking software to add the security. We do this as soon as we think of it, and it quietly sits there, lurking, always visible, preventing the task being marked as complete until somebody gets off their butt and does it.
Or we forget to add that task and it gets to testing and our testers yell at us.
(Oh yeah, I forget to mention: our shop completely blew off the scrum notion that everybody’s supposed to be able to do every task. That’s absurd; humans specialize, and any shop bigger than a garage can afford to hire specialists. And yeah, I get the distinct impression that Scrum was designed by a company with only three people in it working out of a garage, on web development specifically. Those of us who are not three-person teams a garages have to adapt it to our needs.)
We have a security guy on our team. He runs a few automated scan tools before each release, and we loop him in on any changes to our underlying security infrastructure. He’s not typically involved on a task-level basis though.
The struggle is real, and not just for security – web accessibility, maintainability, even usability often get dumped into “tech debt” work items that will never see the light of day because the customer doesn’t care. And convincing them that they should care about something and let us spend a few days here and there cleaning up a mess is an uphill task.
I don’t think any of that stuff was any better under our previous waterfall-ish methodology, but we at least had dedicated shops that most of those things had to go through. The problem there is you spend 3 months working on something and then someone says, “Well did you even think about X?” And we didn’t, but we’re not about to hold up this release for 3 weeks while we go refactor everything, so the customers signs off on the risk and out it goes, never to get fixed again. At least now we have a chance to bring things up every once in a while.
Companies don’t want to hire competent management and develop a decent workforce. They want to create layers of middle managers in bullshit “rent collector” VP roles and outsource the actual work - from development to leading the projects - the cheapest resources they can find.
IMHO, “Scrum” or any of the other flavors of “Agile” is just a very appealing methodology in the age of the “distributed work force” because it lets you assemble a team of total strangers and pretend like they can just pick up and start working effectively.
Theoretically, you should be assigning tasks (or “user stories”) to your sprint that you realistically plan to complete by the end of the sprint. That’s the main advantage of Agile. Done properly each sprint you should have a complete set of work. There shouldn’t be lingering WIP tasks that drag from sprint to sprint.
In reality, IME all project management methodologies tend to fail and degenerate into pointless “crack the whip” meetings, hours of overtime and a “long tail” of critical crap that can’t seem to get done properly.
That’s the theory, and that’s the reason why I’m pretty sure the dudes who came up with scrum/agile/whichever were a three man team working out of a garage on web programming. We, on the other hand, work on real programming in the real world, and for every two bugs that can be flipped in an afternoon there’s a feature that takes a month or more of concerted development and testing. Sure, about half the time we could chop it up into smaller subtasks that might be compilable separately, but only a madman releases half a feature when that half the feature is functionally broken on its own.
The designers of scrum were making toys, and that’s fine for them, but we’ve got an actual application to develop and maintain. So what do we do? I’ve heard of a shop that had month-long sprints, but that’s stupid; instead we just take what we can from the model and discard the rest. And “be releasable weekly” is one of the things that goes quite easily into the bin.
Sounds to me like you’re being led by incompetent idiots. No system will function well under incompetent idiots.
IMO (at least for software companies) Agile/Scrum is the worst form of management structure except for all the others.
Truly, it’s no magic panacea that will fix all the things. But at the very least it acknowledges that designing software up front is nigh-on impossible and it’s better to do things in small chunks and pivot as needed.
We have 20+ teams here, all doing some version of Agile / Scrum / whatever. No team is dogmatic about being purely Agile. All teams bend the rules. So far we’ve stayed competitive with our competitors and it’s a pretty good place to work, so I have no real complaints.
We’ve been doing Scrum for about 4 years here, it’s going pretty well for the most part. There are hurdles and some people couldn’t wrap their heads around the concept, but it really does work. Our releases are more frequent and predictable, and quality for the most part has improved.
The biggest key has been hiring trained and dedicated scrum masters who aren’t coding as well. Lots of stuff gets done by them that really fall by the wayside when you ask a developer or tester to take on the role in their copious spare time.
Not everybody is an idiot. Some people are quite competent in their areas of expertise as analysts, coders, testers, dba’s, solution architects, pm’s, on and on…
But I’ve seen it time and time again in my nearly 30 years as an IT professional having held many of the above roles. An important design decision is made early in the project with the best information available but before anyone involved has a full and thorough, end to end, understanding of what the final product should look like. At some point, after enough sprints, you’ve discovered that the initial assumption is wrong. But it’s too late to re-architect, so everybody plods on (because: burndown time and budget!) acting as if it’s a feature and not a huge fucking mistake. (I find that Agile is particularly susceptible to this point of failure.)
I’m working with a Microsoft team on a $2M project with folks that should know better but have illustrated the above in spades. And the lead engineer on that team sat with me and asked me what I thought they were doing wrong 4 months ago when they started. I told him: scope and time. I also told him that if we were still here a year down the road having this conversation again, I’d not be surprised. I should have bet him a steak dinner.
I know. Everybody is the hero of their own story. Mine happens to be true.
Bolding mine. How on earth would agile be more susceptible to that point of failure? What are you comparing it to, waterfall? In waterfall it would play out exactly the same way. It’s not like waterfall has some solution to the “insufficient information/we didn’t think of that” problem.
Agile isn’t magic and can’t make information appear out of nowhere. About all it has going for it is that, if you follow it strictly, it gives you exit points. But sunk cost is a really enticing fallacy and damn if sometimes people don’t want to throw away months of work. Life sucks and then you schedule a refactor and never get to it because it doesn’t have the priority to float to the top of the backlog.
Successful people are smart and not dogmatic about how they approach problems because not every problem is the same.
Sometimes we are designing software where the user doesn’t know what they need or want and the designer also doesn’t have enough experience in the area to know what will be effective for the customer. This is a good situation to work incrementally and evolve the system as you learn more.
Other times the solution is extremely well understood and evolving the system would be more costly and slower than up front design.
Most of the projects I’ve worked on in my career have aspects of both of these. Current project is a re-creation of a known solution that combines multiple systems from multiple vendors, this was primarily a design up front (in functional area chunks with parallel/overlapping dev/test/config, etc.).
But within this project there were pockets of new territory due to a slightly shifted functional flow, and in those pockets we worked incrementally.
Because the amount of time spent analyzing the problem space up front is limited, therefore you must commit to something with limited information. This is a known trade-off (there is no perfect method).
In waterfall-ish (design up front) methods, you spend more time gathering info, analyzing and designing up front, so some percentage of these things will be found.
Again, no method is perfect, it’s a trade-off.
The real trick is having enough experience to know when to employ the different strategies.
