Womens Hair Re Growth Rogaine Side Effects To Vytorin Lotrel Metformin Accutane After Before Sucralfate Taken With Nexium Hgh Weightloss Shots Can Prilosec Cure Ulcers Diamond Brite Louis Mo Celebrex And Canada Tramadol Is Prescribed For Bactroban Lowest Price Effexor Diary Ring Purim Online Card Music Free Melatonin And Zoloft Interaction Cymbalta Suicide 2006 Avandia Purchase Singulair Phone Cymbalta And Abilify Lexapro Klonopin Alcohol And Paxil Cr Avandia New England Journal Irina Allegra Viagra Next Day Shipping Tricor Pacific Capital Calcaulating Motrin Dose Base On Weight My Dog Ate Allegra D Information On Vytorin Effectiveness Of Diflucan Ventolin Package Insert Craftsman Brite Driver Parts Canada Coreg 25mg Picture Of Generic Nexium Solar Brite Abana Marietta Prosthetic Heart Valves And Coumadin Levels Drug Interactions With Lexapro Ibuprofen Motrin Rainbow Brite Dance Song What Does Synthroid Look Like Lexapro Tardive Dyskinesia Can You Take Celexa While Pregnant Actos Manufacturer Prednisone Use Medication Self-management Coumadin Gneric Viagra Lasix And Heart Surgery Zestril Lichenplanus Cla Supplement Danger Hoodia Bipolar Hoodia Case Studies Flomax For Kidney Stones

Since the dawn of 1999, a few guys like Kent  Beck (eXtreme Programming), Ken Schwaber (Scrum), Alistair Cockburn (Crystal Clear Family), Jim Highsmith (Adaptive Software Development) and Jeff De Luca (Feature Driven Development) with others got fed up with treating the highly uncertain, always moving world of software development as a civil construction project. Traditionally, money and time were spent on writing requirement documents, plans, analysis og design before a single line of value-providing source code was written. Programmers hated it, managers got frustrated and customers never seemed to get what they needed. So these guys decided to change the rules, play a different ballgame, get the job back on the programmers premises. And with the promise that the customers would love it, quality of delivery would increase and each penny spent would provide end-result value. Too good to be true? Well, it worked… most of the time.

So, 10 years later, the Aglie Software development wave has hit home. Most software developers are familiar with the term while others are religious followers of agile stating “there is no other way than the True Way of Scrum”. But seriously, what in fact makes such projects tick? What’s really going on under the hood that makes agile projects successful?

This is basically my background for my thesis which will be completed by January 31st. I promise to provide some sober facts about agile, but also hope to enlight what practices are more valuable than others. Here are some things to consider:

  • “A great team has will have great success with or without Scrum. A shitty team will still produce shit with scrum. Just that the shitty scrum team will see it earlier than the shitty no-scrum team” - a pretty good quoute from someone wise
  • For a creative team to become successful, there must be a certain balance of roles that work together in collaboration, where conflict result in problem solving - not splitting, and where all members take equal part and control over the progress of the project (interpreted from the book “Team” by Endre Sjøvold)
  • For a highly developed team, imposing rules and project governance may hinder them from being efficient at problem-solving. This also goes for light governance principles like Scrum.
  • For a poorly developed team, self-organized teams might not have the momentum, knowledge or power to evolve into a highly-functioning Scrum team, hence will be dependent on the guidance from management.
  • Scrum may impose collaboration but team chemistry can attract or repell team cohesion based on the individuals.
  • Every software team lives in the ecosphere of their company. The company culture and principles of governance will affect the success of Scrum in either way.
  • There may be a big difference in organizing routine support tasks to creative never-been-done-before tasks.
  • Belief can move mountains… or they can certainly be the difference between failure and success in a project… no matter what methodology is being applied.

I hope to discover som interesting facts of what success factors there really are in Scrum and Agile development. Stay tuned :)