If that’s what it takes then it sounds like you are doing it right.
Some things require research, some things can be guessed at, some things require perfect testing, some things can be put in production and tested by the users. There is definitely no one size that fits all.
In my experience, the bane of agile projects is the manager who mistakes “I don’t have to plan everything up front” for “I don’t have to plan anything at all”.
Right, we definitely stretched and bent Scrum to fit. (See all the junk I mentioned above that we don’t do like they say to.)
Though, I will say that I don’t recall scrum having any comment at all on how long it should take to design a story; it was more about locking you into just doing all the actual development from start to test to finish in fifteen minutes, or whatever your sprint is. Admittedly it’s been a few years since I read through the scrum specification, but couldn’t you take as long as you need to design?
I mean, yes, there’s certainly a whole “do tiny things quick” vibe to scrum, but I don’t recall that that was technically a requirement of the design phase.
Heh, my manager lately has taken the approach, “We want to do this, go play with it and figure it out, and come back to me and we’ll discuss how it should work.”
And then I’ll say, “Okay. By the way, where’s the story for it?”
“There isn’t one yet. You put it in. Just leave everything but the title blank for now.”
“But it’s not my job to put in stories!”
“Do it anyway.”
In general, agile-ish proponents have traditionally pushed back against “big design up front” due to following:
1 - Sometimes the customer (and/or designer) do not know what is a good solution for the problem, guessing will result in wasted time
2 - Business changes so rapidly that a big design up front will not be relevant by the time the code gets put into production
Both of those things are sometimes true and sometimes false, so no one solution can always apply.
Well, there’s design and then there’s design. Which button is on which form is generally a matter of nobody cares, but if you’re winging it on the overall concept and the data flow, you’d better be damn well prepared to rip out and roll things back out when you finally get around to figuring out what you actually want to do, or when you finally probe deep enough to find out what the problem is.
Here’s my hero story - a month and a half ago I was working on an integration, and started getting the sneaking suspicion that the company I was integrating to was 1) British, and 2) not going to be returning amounts in the USD our program expects/requires. I informed my boss of my fears. Some cursory investigation was done and I was told that no, it would be okay, just keep working. Two weeks later I walk in and say nope - no USD, no way, no how. Period. Summarized my evidence in a flat and firm sentence.
I was promptly told to roll it all back, while they frantically scrambled for an alternative thing to integrate to. (We have contractual obligations - new features or bust. (Which new features is apparently not all that important.))
A seemingly comparable alternative was found. I was told to integrate to it. There would be no deadline extension. I began, hurriedly.
Four hours later I was told, forget that one, integrate to this one instead.
My head exploded from the stress and instability.
A week later I turned that one in, having cannibalized chunks of the british one to put it together.
Since I was ahead of schedule and all, they decided I was going to do the other alternative too. More cannibalization occurs. I sent that one to testing yesterday.
Scrum is fun! :smack:
It wasn’t my intention to suggest that all Agile based IT projects are doomed to failure. Nor did I mean to imply that Waterfall is without it’s own set of challenges.
Its possible to manage and deliver successfully executed IT projects/products. But Agile is not a magical SDLC methodology, and I wish people would stop playing catch-word bingo when it comes to planning, building and delivering quality IT solutions.
We pretend to scrum. But we’re really more kanban.
No, it’s not magical. But in my experience it allows teams to deliver more predictable product and value to customers. Your experience may differ, and I’ve seen Agile done very poorly. But done properly, we’ve found it to be an improvement over waterfall.
I don’t see any “method” at all, sir…
No, I think **begbert2 **hit the nail on the head.
Well, that’s the trick, isn’t it?
It’s not necessarily whatever specific buzzworthy technique you use but finding/hiring/training people to take care of what would be considered ‘non-essential’ or ‘negative cost centers’ by clueless corporate overlords.
If you have competent, trained people in those sorts of roles, you are likely to see more consistent quality and improved results…just as if you generally train and retain competent employees, you would generally do well in any event.
But the same clueless overlords may not necessarily bother with making sure managers are adequately trained or even competent. Agile, properly implemented, should work fine. But then again, that’s true for a lot of setups - if a company takes care to find, retain, and train its employees, most project management methodologies should work fine (does it work optimally? that’s hard to define in any event). But if it requires pasting some kind of fancy label on top of that to get them to sign on to the notion that some investment should be made in employees, then fine.
The flip side is then any failure to see results is called a failure to properly implement Agile. Well, that’s true but most organizations that fail to do so typically see it as a cure-all, magic solution rather than what it really is - a way to simplify/codify the basic things we should be doing anyway, i.e. splitting tasks into smaller, manageable, specific chunks; focusing on regular communication between team members; getting regular feedback from clients/end users; reducing unnecessary complexity in projects; etc. These are things that should be relatively obvious, but larger organizations often lose the forest for the trees.
I like your testers 
I’ve never done anything that really sounds like what I read on sites explaining Agile or Scrum; I’ve had managers who insisted that we were doing Agile but the only consequence appeared to be a change to some of the corporate buzzwords. In fact, SAP has a “map of how to do a standard SAP implementation” and a “map of how to do an Agile SAP implementation”: at one point I was so bored at work that I compared the two, step by step, until I found the one (1) step which was different.
On the other hand, the one manager who insisted we had to Waterfall… I call him the Concretefall guy. This isn’t the kind of thing where you can expect to have complete, perfect and unchangeable designs before you even start looking at data, damnit. What should have taken 9-12 months took them 4.5 years: I know because once they were finished, one of the people in that team gleefully announced the end of the project (and his retirement) to all and sundry who’d ever suffered it.
There is basically one working Scrum pattern and one failing Scrum antipattern.
When it works, we’re basically admitting that the understanding and definition of the problem changes so fast that it’s pointless to perform detailed planning more than N weeks in advance. So we only do short-term planning cycles and deliver incrementally.
When it fails, it usually means a manager has observed a working Scrum implementation, they are excited to see that their workers have to report progress daily, and they copy the processes and ceremonies that make people report status as often as possible.
Guess which one is more widespread.
I’ve embraced Marie Kondo.
I’ve had managers who did that without any references to Scrum or other management philosophies. I call them “the She-Lobettes”.
My last employer did a fucked-up hybrid of Scrum/Agile where the development side of things (developers, testers and analysts mostly) were doing something Scrum/Agile like. Meanwhile the business and upper IT management were still thinking and behaving in a top-down kind of fashion. And on top of all of it, we weren’t dedicated to one project at a time either.
It. Did. Not. Work. Well.
It devolved into a set of daily meetings where the product owners/scrum masters behaved as if their projects/sprints were THE most important thing every single fucking morning, the upper management wanted updates on project timelines without any reference to sprints, iterative development, etc… and they always wanted detailed BRDs ahead of time (which somewhat negates the idea of doing sprints and iterations). Meanwhile, us worker bees were trying to balance it all while being pulled in multiple directions.
I think it’s got a lot of value if you’re somewhere where the entire enterprise is centered around the concept, like say… a software shop that produces software as a product. But it doesn’t work in a corporate IT environment when the business is thinking top-down waterfall, and you’re trying to graft scrums and sprints onto that. That just means that everyone gets harassed each and every morning about each product, and doing product iterations is viewed as taking time away from time/dead lines that have to be met to keep the business happy.
I am not a fan of Agile/Scrum as a overriding philosophy of business management or project management. It requires too many things to be in place to actually work effectively at all without being oppressive, that it’s not something that I feel can be effectively implemented without total buy-in on the part of the ENTIRE company.
I actually quit my job of 9.75 years in no small part because the Agile-ish BS we were doing was so god-awful. I’m a responsible, capable professional, and I’ll get it done by the deadline, or have a really good reason why I can’t, that I won’t spring on you at the last minute. I don’t need some dickhead harassing me every single morning about where I am on things on a particular two week block of stuff, especially when I have another project I’m working on, as well as a fair amount of standing support responsibilities that HAVE to get done.
Just to point out, that a properly run morning standup shouldn’t be doing any of those things. Ours certainly aren’t like that.
What do you get out of the daily morning standup that you could not find out on your own if it was necessary for your specific role and set of tasks?
I’m trying to get to a place in my life where not everyone who disagrees with me is an “idiot”. You’re not helping. 
I once had a CEO who insisted on everyone making a daily status report, in an email sent to a particular address. Management would give people a hard time if the status report wasn’t received, but they were very conspicuously not reading their contents, just checking whether they came in.