The problem with both waterfall and agile is that we are missing the definition of "the Humble process" to develop software.
Unfortunately humility does not sell so well.
We've invented waterfall
131–140 of 172 posts
Re: We've invented waterfall
#132Earlier quoted context omitted.
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…
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…
Sounds a bit like the guy who had some really good advice to give, but didn't take into account the politics and context of the forum he was posting to, tagged it with a douchey comment at the end, and got downvoted and ignored.
Re: We've invented waterfall
#133Earlier quoted context omitted.
Interesting point until the twatty comment at the end.
I just love how much sound advice we discard because of our feelings towards someone/something. Ever read Stuart Sutherland's Irrationality?
I agree with the sentiment, but how can you know to trust someone's advice if they're acting in a way that's obviously very socially stupid? (I'm not huge on excessive politeness, but I think it's quite stupid to be aggressive for no reason. What purpose does that serve? Why should I trust the advice of a person that acts that way?)
Re: We've invented waterfall
#134Earlier quoted context omitted.
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…
Wow. Thanks for sharing that. This paints a really clear picture of why so much enterprise software are pieces of crap.
Now don't overgeneralize... There are lots of other reasons why enterprise software is crap.
Re: We've invented waterfall
#135Earlier quoted context omitted.
The surprising thing isn't the policy. The surprising thing is the persistence of the policy even after it's no longer beneficial in any way. It's been more than a decade since Ethernet auto-negotiation became reliable. During that decade, that company has paid for a team to go around and do manually what could have been done by an automated process for a trillionth of the cost. That's a staggering amount of waste.
The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.
Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.
Re: We've invented waterfall
#136Earlier quoted context omitted.
The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.
Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.
But who will regularly review the policy on reviewing the policy on regular review of policies?
Re: We've invented waterfall
#137Earlier quoted context omitted.
I'm totally not getting why you're saying agile approaches are waterfall in disguise. The essential difference to me is in length of feedback loops. Microsoft releases a new OS every few years; some place like Etsy releases new code many times a day. A developer or product manager at Etsy can know within a few hours whether some change is really a good idea; Microsoft not so much. You seem to be saying that because t…
Nope, it has nothing to do with the commonalities in people or roles, sorry I wasn't clear. Let me try again. It's a knock on all rigid processes and dogma, not agile in particular. I trimmed the rant down by taking out the sections that rip into UX firms, with their Big Upfront Design and cocky rockstar designer personas, but it could just as easily been about them. I only cut it because I thought the parallels were…
Yep! I get it now. Thanks for clarifying.
I agree that "agile" teams that group people by specialty are clueless. Done right, the teams are, as you suggest, cross-functional. That was the original intent for the people who coined the term Agile, but much of that has fallen by the wayside as larger organizations decided Agile was fashionable and consultants rushed in to sell them 3% dilutions of XP or Scrum.
I've written more about how that happened here, and a lot of the early Agile types I've talked to agree: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
Re: We've invented waterfall
#138Earlier quoted context omitted.
The term "waterfall" wasn't coined by Royce in his paper. His paper was a set of suggestions to improve what later became generally known as the waterfall process.
And Royce was ultimately advocating an iterative method (rather than a strict waterfall), not unlike most agile methods today, although his cycles were much larger. If one is interested in software development methodology, I strongly recommend taking 15 minutes to read the actual "waterfall" paper[1]. Poor guy, Winston Royce is one of the most misunderstood folks in the industry. (By the way, curiously enough, Royce'…
He wasn't advocating iterative methods in the agile sense, in fact he calls for "complete program design" before any analisys or coding, along with intensive documentation, planning, controlling and monitoring. An iterative approach to development drops nearly all of those.
The graphic where he shows cycles going back stages is used to exemplify failure, which he proposes to fix via the strict practices above.
Re: We've invented waterfall
#139Earlier 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:…
Seems to me the C-level execs should have given you more cover. It's their job to manage their organization, not yours. This strikes me as a failure of leadership on their part.
Re: We've invented waterfall
#140Earlier quoted context omitted.
Nope, it has nothing to do with the commonalities in people or roles, sorry I wasn't clear. Let me try again. It's a knock on all rigid processes and dogma, not agile in particular. I trimmed the rant down by taking out the sections that rip into UX firms, with their Big Upfront Design and cocky rockstar designer personas, but it could just as easily been about them. I only cut it because I thought the parallels were…
Yep! I get it now. Thanks for clarifying. I agree that "agile" teams that group people by specialty are clueless. Done right, the teams are, as you suggest, cross-functional. That was the original intent for the people who coined the term Agile, but much of that has fallen by the wayside as larger organizations decided Agile was fashionable and consultants rushed in to sell them 3% dilutions of XP or Scrum. I've writ…
That's a great writeup! I know exactly how you feel except my disappointment was doubled, because I was a hybrid developer/designer for years before completing the switch from developer to designer and I lost the faith in both agile and UX at about the same time.
I wish I had the courage to write up my disappointment like you did, but I'm happy that I've moved on to a meta-process of borrowing from different techniques as needed.