Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
We've invented waterfall
91–100 of 172 posts
Re: We've invented waterfall
#92The long and the short of it for me is this: There's two ways to solve problems. Agile helps immensely when you are figuring out how the solution would work. When you're solving a problem that might be solved in manual processes largely, Waterfall can help a lot, but not alone.
For unknown solutions, agile gives you a lot of iterative benefits.
For known solutions, waterfall with some agile feedback loops gives you incremental benefits.
What's the difference?
Sometimes, in a business, they have a great process already. It's in paper, or multiple systems, but they have their way of doing things that works. I believe it's called their competitive advantage.
Othertimes, a business is facing a problem for the first time, and wonder "how do we solve this". In this case, doing a big upfront design is a waste of time, starting small and staying flexible is most important.
For me, this mindset of doing both is critical, not one or the other at all times. You simply miss out on too much if you don't use agile, and you run around too much if you ignore waterfall when a solution exists.
Waterfall works where it's a known process, like building a house. You can have agile loops in there when building a house and improve it as you go.
When you're trying to build a new building that's never been built before, an iterative, feedback-centric approach like Agile is a lot more beneficial.
If a company focuses on taking something like Waterfall and introducing feedback loops (agile) like this epicenter thing, is it not a bit clearer than the black-box voodoo out there? Maybe it's just me, but I applaud anyone trying to make software easier. It just shouldn't be a dogmatic, or religious dismissal.
0.02.
Re: We've invented waterfall
#93I don't talk to anyone.
I look at the crap you're using and make something new.
I give you the URL.
Figure it out on your own.
Invoice due on receipt.
Re: We've invented waterfall
#94Earlier quoted context omitted.
There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a frac…
Personally, I see a very clear line between culture and politics. The people of the various departments didn't have any conflicts. It was strictly between department-heads. And, for what it's worth, the C-level types loved the project too. What I did was replace a wooden peg with a modern prosthetic and upset the guy who was selling wood oil for conditioning the peg and the guy who sold the leather straps [1]. edit:…
But thats the thing. You should count politics as part of your requirements too, or thats what the theory states anyway.
For example, lets say you digitized an inventory form for a sales dept of a plastic company. By doing this, you effectively removed use of a pen from the 'system'. Now what politics could you possibly be affecting by eliminating use of a pen? Well, you could cause an uproar between the finance dept and the sales dept. Finance says that the organization's major stock holder is a pen company and the sales department must use pens (for whatever reason...lets pick advertising and promotion).
Now your system made the world efficient but it failed to account the current work practices of your client. You, sir, just screwed up.
Re: We've invented waterfall
#95Re: We've invented waterfall
#96Earlier quoted context omitted.
There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a frac…
Interesting point until the twatty comment at the end.
Yeah yeah yeah...but I did come bearing gifts!
Re: We've invented waterfall
#97Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…
Why? The company had a long-standing policy of manually setting speed and duplex to ensure that there were no duplex mismatches. The was a team of 6-7 people who would audit servers and check switchports, and they produced a report was issued every week, and reviewed by the CIO and other luminaries. People would be shamed for errant configurations, as only the auto-negotiation team could configure NICs.
The director who controlled the auto-negotiate squad was politically powerful, and got all sorts of power out of it -- including banning GigE. As late as 2010, this org was deploying dozens of 100MB NICs to ESX hosts to get sufficient bandwidth. They also purchased 100MB NICs for desktops.
Re: We've invented waterfall
#98Re: We've invented waterfall
#99Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…
It made the initial sales much harder, but the results are much stronger and we've gained such a strong reputation that the software almost sells itself.
Re: We've invented waterfall
#100Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.
Perhaps not. But they're probably running a computer model of the jet (and its systems) under various simulated scenarios. They're also probably building some full-scale mock-ups to test in wind tunnels. And they also have test pilots to fly things which sometimes never make it into wide scale production. So, I'd argue that there is some iteration going on there.