This is a great article to better understand Agile as a methodology and a recap of several of Agile's core values.  You will also gain some insight into why agile can fail and why agile is not a 'software delivery methodology.  Happy reading...

Discussions on what constitutes a “proper implementation” of test automation often focus on what tool you should use, but that is only one part of the equation. Bas Djikstra details four other things you should consider, how they contribute to the success of your test automation, and what risks are associated with failing to pay proper attention to each of them.

Nearly every CIO or VP of R&D is struggling to improve their time to market while increase the number of features delivered within stagnant or shrinking budgets. Two objectives of software development teams will address this need are to improve predictability and optimize productivity By combining views of predictability and productivity of the development activity, the team and its stakeholders can quickly and easily tell if the development is on track, if predictability is improving, and if team members are self-aware enough to improve their overall output.

Over the past year, I have had many conversations with people both inside and outside of Red Hat that always seem to revolve around two questions (much to my dismay and squinty-eyed loosquintyk when asked):

• Where are we going with Agile in the Products & Technologies division at Red Hat?
• When is your team going to standardize the process for the entire division so everyone is doing the same thing?

When you first started with git, you quickly got up to speed with committing, pushing, pulling, merging, and the like. But then you noticed a gaping hole in your knowledge — how do you find stuff in Git? Can you revert to a version of a file as it stood three weeks ago, or find out when a bug was introduced? Who was the last person to edit this file?