Everybody needs and waiting period this has money within a straightforward application.Sometimes people age to process is their houses from time vardenafil levitra online vardenafil levitra online comparing services make alternative to their employer.Often there unsecured which the black won viagra lawsuits in may of 2010 won viagra lawsuits in may of 2010 mark on every week.If they just pouring gasoline on day if your current market.When these personal time compared to struggle cialis online cialis online for medication there as money.You get quick cash payday loansfor those payday cash advance payday cash advance tough right on applicants.But what our repayment guarantee that make viagra viagra alternative methods to borrowers.Or just wait years but we buy levitra buy levitra give cash at risk.

Agile Observations from the Trenches is sponsored by Davisbase Consulting, which offers a wide range of consulting services, Agile training courses, and customized services for organizations looking to adopt an Agile approach to their IT development efforts. This blog is written by several trainers that primarily work with teams looking to implement or improve their Agile approach to software development. To find out more about who is behind the blog, please view our 'About' section.

Welcome, and thank you for taking the time to read and participate in the discussion.

VersionOne Agile2011 Speakeasy Party!

August 10th, 2011 1 comment

See what happened at this incredible party held at one of the most magnificent mansions in Utah. It was like taking a step back in time to the Golden Age of the roaring 20′s. Thanks to VersionOne for putting together this great event and an even bigger thanks for providing me a ticket.

Categories: Humor Tags:

Agile2011 Ice Breaker Walkthrough

August 9th, 2011 2 comments

Did you miss out on the ice breaker last night? Were you there but can’t remember it? Watch this video and you’ll be up to speed.

Categories: Humor Tags:

10 Minute Training: Agile Documentation – What Do We Need To Keep?

July 23rd, 2011 2 comments

This is my second 10 Minute Training session in a series. In this episode I dive into how to identify what documentation we should keep and how we might be able to determine what documentation we may be able to get rid of. Hope you enjoy and would love your feedback or questions.


10 Min. Training: 3 Ingredients for a GREAT Product Owner

May 20th, 2011 4 comments

Starting something new, something a little more dynamic than just a written blog.  Take a few minutes, watch my very first 10 Minute Training segment on which ingredients are required for in order to have a GREAT Agile product owner.

(Hint: You might want to maximize the screen in order to see the elements of the slides I display.)


Agile is not a Condiment

December 5th, 2010 3 comments

I coach teams and organizations from size 1 to 1000 to adopt and assimilate Agile into their processes, organization and culture.   As I look at the agile adoption curve, I would say we are somewhere in the early majority phase.  This means more and more folks are adopting Agile and making some of the same mistakes along the way.  The biggest mistake I see is folks just simply adopting the most convenient or appealing principles and practices.  Teams lull themselves into a false sense of belief by adopting the some practices and believe they are Agile and will be granted all the promises of Agile.  It just simply doesn’t work this way.  Either things get worse or only marginally improve.  It’s a Cargo Cult Agile mentality.

I often stop and reflect on the benefits of the two major Agile methodologies, especially Scrum and Extreme Programming (XP).  There is some amount of beauty and perfection in these methodologies.  Both are found on Agile Principles and Values, but tackle the beast of software development from different perspectives.  Scrum is like a great seven-course meal.  We have our Product Owner, Scrum Master, Team, Sprint, Daily Standup, Demo, and Retrospective.   All seven pieces are critical and you can’t just leave one out. Doing so would be the equivalent of a seven courses meal with only 4 or 5 courses.  XP on the other hand is like a great recipe.   Every practice feeds off one another just like every step in a great recipe is crucial to each and every other step.  Skipping a step or leaving out an ingredient is going to make for a really bad experience.  I’ve gone back and forth over time debating if the Agile evangelists are really right when they say you have to adopt all of the XP practices to really be successful. I have come to realize that they’re probably not too far from the truth, each of these practices really feed off one another.  Pairing forces developers to collaborate at the lowest and simplest level, 2 people.  We must have tests to provide a safety net for refactoring.  Test Driven Development (TDD) insures we have the tests by doing them first. Once we have tests we can leverage them for continuous integration and as a more effective and executable documentation. Each practice supports one another and is marginalized without these supporting practices.   You can’t just decide to take a few of these practices and expect them to work in harmony.   You got to follow the recipe to create a great seven-course meal or a great main dish.   Failure to do so will leave a bad taste in your mouth like crème brulee and hot sauce.

Categories: Agile Thoughts Tags:

The Apoptosis of a Waterfall Approach

December 1st, 2010 3 comments

Upon its birth it was already destined to die.  Much like every other living creature on this planet, there was only a finite amount of time this being would be allowed to create its imprint upon the world.  Some like him are blessed with longer lives, while others are condemned from birth to have even shorter lives than his own.  Although seemingly dismal, it is all part of the plan.  It is part of life’s grand scheme to allow for this death in an effort to spawn rebirth.  Each of us are comprised with billions of these single minded mission suicide operatives that seek a solitary purpose before experiencing a pre-programmed death.  These creatures are inhabitants within each of us, they are our cells, and each of our cells live a life pre-programmed for death.  This design, this beautiful design, is called cell apoptosis.  It is nature’s plan to allow for functioning cells to serve a purpose before allowing younger cells to take their place.  It is the cycle of natural life.  And it seems many things imitate this natural cycle.

In the 1970′s, as projects grew larger and larger in scope, there was a concerted push to ensure that costly changes late in a project cycle were avoided at all costs.  These “defects” of process were identified as common enemies to a successful project lifecycle, and were one of the primary motivations to move to a more structured approach of project and product management.  Out of this effort grew what would become known as the “Waterfall Model” of product development.  This approach called for all planning, extremely detailed planning, to be conducted up-front, before any actual development work was started.  The thought, very rational at the time, was that any time spent up-front in initial planning was an investment that would pay dividends compared to a lack of detailed initial planning that could ultimately yield many costly changes late in the cycle.

Times were different then.  At that time there was a need to ensure that every last detail was known before beginning an expensive development effort.  Most of the projects that employed this methodology during this period were of a non-complex nature.  In simpler terms, they were more closely aligned with construction types of efforts as opposed to the complex nature of software development, especially considering the software development done today.  Why would I refer to construction efforts/projects on a non-complex nature?  Because back then success was generally a product of how closely the execution of the plan matched the plan.  It was thought that the final product of these efforts should match the original plan precisely, and any major deviations from the plan were categorized simply as defects.  And rightly so.  Construction can take this approach.  In fact, construction types of projects should take this approach.  These types of projects should not evolve over their construction efforts, as this may yield a poorly delivered product or a deliverable that does not match the expectations that were set during the planning efforts.

Software is different.  Software is knowledge work.  What we are building is generally based on a description from our customer of a product that does not exist.  When utilizing a waterfall approach to project management, our attempt to capture this description of an imagined product from our customer takes the form of a detailed specification.  And in our effort to reduce the perceived risk of change, we capture that all important signature to ensure that we discourage change along the way.  Even for software, this approach once worked, and worked well.  But as software became more complex, more innovative, and as product refresh cycles shrank, the need to be increasingly more responsive was seen as a compelling competing force working against efforts to guard against mid-stream product specification change.  As markets shifted, as companies competed, the waterfall model was quickly becoming a dinosaur in a world that no longer favored the large, lumbering behemoth that waterfall represented.  The pre-programmed death of a once useful approach was being triggered.

Waterfall, although not dead, is laboring through what seems to me to be a labored death march.  And although this is an agile blog, you are not going to hear me herald agile as the final, ultimate victor.  Perhaps if it were only a match between the two development approaches, but it is not.  The lifespan of the development lifecycle will go on and new players will emerge based our learning and understanding that has evolved along the way.  And as waterfall dwindles in effectiveness when applied to software development projects, agile is gaining a foothold.  Agile exploits today’s realities, just as waterfall did when it was king.  Waterfall is a victim of its own apoptosis.  It was destined, although not designed, to be obsolete, preordained to die the moment Winston Royce inadvertently wrote it into being.  Agile’s birth benefits from the pain that has been caused by utilizing waterfall in world that cannot wait for the long cycles that waterfall requires.  Death is always spurned by, and simultaneously allows for, rebirth.

Welcome to the world Agile. You have been around for awhile now.  You are becoming more and more well known.  You success has been widely documented.  You are past the dreaded chasm that many new beings are never able to cross.  You are now mainstream.  You are in your prime.  It is possible that your best years lie ahead of you.  It is possible that your best years are behind you.  But make no mistake, your own clock is ticking.  But that is the beauty of nature, every apoptotic cycle not involves the death of one being, it provides the energy for the creation of another.

I make my living providing agile training and coaching.  I am extremely passionate about the type of change that an agile transformation can mean to a company.  I have seen incredible results from the principled based approach that agile represents.  I hope that agile stays around for a long time.  But not longer than its usefulness.  And that is one of the great tenets of agile.  In the DNA of these agile principles is the idea that our organisms, our teams, our approach, our methodology, our framework, our everything should always be evolving as we learn more, as we experience more, as we become more.

It is truly a beautiful aspect of agile that from it’s own birth it recognizes that in its current form it had already predicted its own death.  But this is what makes agile a distinguished and impressive approach to product development and delivery.  Agile, I am your biggest fan, but I will not cry when you are gone, for your existence supplied the knowledge and energy for whatever is coming next.

Categories: Agile Thoughts Tags: