Water vs. Agile project methodologies

I am about ready to jump on a webinar on Agile and Waterfall methodologies.

Agile Meets Waterfall: How to Manage Multiple Methodologies

January 14, 2014
11:00am — 11:59am PST

FEATURED PANELISTS

Rich Morrow
Rich Morrow founder / head geek,quicloud LLC
Dave Ohara
Dave Ohara Founder, GreenM3
Jesse Dowdle
Jesse Dowdle Director of Engineering,AtTask

MODERATED BY

Cormac Foster

Agile methodologies have had tremendous success in task-oriented teams and are increasing their penetration into the enterprise. Still, Agile is just a tool, and not all projects, business processes, and corporate cultures are natural fits. But managing multiple methodologies can be an enormous challenge without the right approach.

Since I am talking on the subject I decided to write a bit first as notes to myself.

So, what is Waterfall Methodology?  Here is a post that compares Waterfall and Agile.  I’ll pull out nuggets that gives you the high level concepts.

What is the waterfall methodology?

Much like construction and manufacturing workflows, waterfall methodology is a sequential design process. This means that as each of the eight stages (conception, initiation, analysis, design, construction, testing, implementation, and maintenance) are completed, the developers move on to the next step.

...

Advantages of the Waterfall Methodology

1. The waterfall methodology stresses meticulous record keeping. Having such records allows for the ability to improve upon the existing program in the future.

...

Disadvantages of the Waterfall Methodology

1. Once a step has been completed, developers can’t go back to a previous stage and make changes.

...

What is Agile?

Agile came about as a “solution” to the disadvantages of the waterfall methodology. Instead of a sequential design process, the Agile methodology follows an incremental approach.

Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run.

...

Advantages of the Agile Methodology

1. The Agile methodology allows for changes to be made after the initial planning. Re-writes to the the program, as the client decides to make changes, are expected.

...

Disadvantages of Agile Methodology

2. As the initial project doesn’t have a definitive plan, the final product can be grossly different than what was initially intended.

Server Automation - 4 choices - Puppet, Chef, Ansible, or Salt

Here is an Infoworld article one of my friends sent that reviews the 4 choices for server automation.

Review: Puppet vs. Chef vs. Ansible vs. Salt

The leading configuration management and orchestration tools take different paths to server automation

By  | InfoWorld

Follow @pvenezia

Print|15 Comments
 
Review: Puppet vs. Chef vs. Ansible vs. Salt

Credit: Teerawut Punsorn

The proliferation of virtualization coupled with the increasing power of industry-standard servers and the availability of cloud computing has led to a significant uptick in the number of servers that need to be managed within and without an organization. Where we once made do with racks of physical servers that we could access in the data center down the hall, we now have to manage many more servers that could be spread all over the globe.

I know people who are hard core users of each, so even though the reviews may make you think one is better than the other.  There are some who have found that one particular tool works best for them.

This will probably all change over the next year as each add more features.

One of the Good Things About Obamacare's IT disaster is the possibility of the end of Waterfall Development in Government IT

This whole Obamacare IT stuff is going to keep going for a while.  The rest of the Tech industry can sit on the sidelines and let the US government and its vendors take the hit for outages, security breaches, bad customer service.

One of the possible outcomes is the end of Waterfall development.  The WSJ journal reports on a call for openness and transparency in development.  Words that sound like Agile Development.

The administration "must be fully transparent in their efforts to get the website working. Anything less than complete disclosure and accountability is not acceptable," she said.

Here is one amongst many comparisons of Agile vs. Waterfall.

Agile Vs Waterfall Model

It is worth mentioning here that the Waterfall model is the primitive model type and has been implemented in the development phase time after time. Hence in the due course if time developers found many drawbacks in this model which were later rectified to form various other development models.Waterfall Vs Agile pictureThe common element to all of them being the basic phases of the waterfall approach. We can hence conclude that Agile is also another of its successors which has all the advantages of the primitive waterfall model and has also rectified the disadvantages in this evolved model.

Slate.com dives into the details on Healthcare.gov issues, discusses back-end server issues

Healthcare.gov's availability and usability is in the new since Oct 1 launch.

Slate.com has a post on what is behind the problems.

They are finding Oracle DB errors.

“Error from: https%3A//www.healthcare.gov/oberr.cgi%3Fstatus%253D500%2520errmsg%253DErrEngineDown%23signUpStepOne.”

To translate, that’s an Oracle database complaining that it can’t do a signup because its “engine” server is down. So you can see Web pages with text and pictures, but the actual meat-and-potatoes account signup “engine” of the site was offline.

And who the contractors are for the client web front end and the back-end.

This failure points to the fundamental cause of the larger failure, which is the end-to-end process. That is, the front-end static website and the back-end servers (and possibly some dynamic components of the Web pages) were developed by two different contractors. Coordination between them appears to have been nonexistent, or else front-end architect Development Seed never would have given this interviewto the Atlantic a few months back, in which they embrace open-source and envision a new world of government agencies sharing code with one another. (It didn’t work out, apparently.) Development Seed now seems to be struggling to distance themselves from the site’s problems, having realized that however good their work was, the site will be judged in its totality, not piecemeal. Back-end developers CGI Federal, who were awarded a much larger contract in 2010 for federal health care tech, have made themselves rather scarce, providing no spokespeople at all to reporters. Their source code isn’t available anywhere, though I would dearly love to take a gander (and so would Reddit). I fear the worst, given that CGI is also being accused of screwing up Vermont’s health care website.

Part of the reason why this post makes sense and is researched well is it written by a SW developer.

 

About

davidheadshot-300x221I am a writer and software engineer. I’ve worked for Google and Microsoft. I live in New York with several thousand books. I have contributed to Slate, the Times Literary Supplement, The Nation, n+1, Bookforum, Triple Canopy, The Quarterly Conversation, and elsewhere.

The closing remarks are proof the author knows what he is talking about.

Bugs can be fixed. Systems can even be rearchitected remarkably quickly. So nothing currently the matter with healthcare.gov is fatal. But the ability to fix it will be affected by organizational and communication structures. People are no doubt scrambling to get healthcare.gov into some semblance of working condition; the fastest way would be to appoint a person with impeccable engineering and site delivery credentials to a government position. Give this person wide authority to assign work and reshuffle people across the entire project and all contractors, and keep his schedule clean. If you found the right person—often called the “schedule asshole” on large software projects—things will come together quickly. Sufficient public pressure will result in things getting fixed, but the underlying problems will most likely remain, due to the ossified corporatist structure of governmental contracts.

Apr 4, 2011, Google shifted from analytical data driven to an emotional customer driven design focus

When I left Apple in 1992 for Microsoft I was one of the few Apple employees to move to Microsoft.  Over the years many more Apple employees joined Microsoft, and now many more Microsoft employees have gone to Apple.  

One of the questions many asked when I first joined Microsoft was what is the difference between Apple and Microsoft.  After months of explaining I finally hit upon the following.

Microsoft is an analytical company, doing things that there is data to support the decisions.  What makes people feel good inside the company is having data to support a decision.  Apple is an emotional company where you do things that feel good for the customers.  Usability testing rarely taps into the emotional element of do people like the new service.

This split is a religious one.  Designers on one side.  Developers on the other.  Until April 4, 2011 Google had a shift in the balance and afterwards designers got more votes on what Google shipped.

Here is a post on Fast Company.

How Google Taught Itself Good Design

LONG DOMINANT IN ONLINE SEARCH, ADVERTISING, AND MAPS, GOOGLE HAS SHIFTED GEARS FROM UTILITY TO BEAUTY--AND IS NOW MORE FEARSOME THAN EVER.

...

If you ask a Google designer to mark the shift between Google's old approach to design and its new one, you're likely to get a precise date: April 4, 2011. That's the day Page became CEO. It's also the day Google designers were set free. Within a week of taking over, Page called together the company's top designers, product chiefs, and executives to outline his vision for Google's aesthetic future. Page's ideas meshed with a plan that designers had long thought Google should embrace.

Leading up to 2011 was the reality of 2010 user feedback.

 In 2010, Google conducted a series of user tests to find out how people felt about Android. The results were stark: "A lot of people felt that Android was essential to their lives, but they didn't like Android," Duarte says. The robust abilities of the OS "made them feel small. It wasn't empowering, but daunting." The same could be said for other Google products. When you loaded up something made by Google, you were more likely to feel overwhelmed than welcomed.

How much voice do you give your users?

Do you design for your users or your developers and internal views?