What Agile Processes and Diets Have in Common

I have spent a great deal of time lately reading blogs predicting the end of Agile. There are a lot of good people making a lot of good points but I think that there are some major problems the arguments predicting the end of Agile.

There is a very real tendency for people to confuse Agile (the philosophy) with Scrum (a process created to achieve the principles of Agile). Agile is only 16 statements – 4 values and 12 principles – nothing more. Of those 16 statements I am sure that there are some who would argue against them, but these would be a fringe element. Don’t believe me? Follow the links above and see which, if any, a rational software developer or business person would disagree with. You can disagree with them, but principles, in and of themselves, cannot fail.

Continue reading What Agile Processes and Diets Have in Common

The Fourth Agile Principle

“Business people and developers must work together daily throughout the project.”

I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.

Continue reading The Fourth Agile Principle

The Reason Your Agile Implementation will Fail

I have had the good fortune of managing Agile (scrum) implementations at a number of different companies over the years. I have had some great success and some implementations that were not so great. While not unique, my experience is such that I have enough data points to start seeing patterns, especially patterns of failure. That is, while I cannot confidently tell you what will most certainly work in your particular situation, I am eminently qualified to tell you what will not work.

Continue reading The Reason Your Agile Implementation will Fail

Not Burning Down? Diagnosing and Fixing the Some of the Problems

Of course you would not expect every sprint to have a perfect burndown. You would not expect to complete every story in every sprint (my goal has always been 90% or greater stories complete), but if you are finding yourself with many “overhanging” stories each sprint there are a number of things that you can do to diagnose and fix the issue. In this particular post, I am going to discuss problems with time and hours.

There are three things that can go wrong with hours:

  1. The number of hours the individual estimates for capacity is too low.
  2. The number of tasks identified is incorrect (not enough tasks identified).
  3. The number of hours associated with each task is too low.

Continue reading Not Burning Down? Diagnosing and Fixing the Some of the Problems

What to Expect from a New Agile Team

Whenever I work with a new Agile team I have some stock “speeches” that I tend to give. One of my favorites “speeches” covers my expectations are for a newly formed Agile team, namely increased transparency and predictability.  Notice that I did not say increased velocity. That may or may not come with time, but the first two hurdles are getting to a point where one can understand what is going on at any time – transparency – and what can be expected to be delivered over time – predictability.

One of the biggest hurdles to getting any software development completed is endless interruptions. Transparency provides a safe haven where anyone associated with a project can see where the team is at anytime so that constant status and interruptions can be calmed.

Continue reading What to Expect from a New Agile Team

Chaos to Waterfall to Agile – The Evolution of Software Development

I spent some time recently in a PMO meeting about project  metrics. Seems that the big bosses want to create some service level agreements based on these metrics. The most interesting part of the meeting was sitting back and watching the process. As an Agile proponent I was amazed at the lunacy of central planning. Each project was on a master project list and resources (humans as I like to call them) were assigned based on their time estimates. These folks were scheduled months in advance. During the meeting, the leader of the PMO said that it was incumbent on the individual project manager to make sure that the assigned resource begins and ends their work as based on this long-term plan. Anyone who has spent any time in software development should realize that the odds of the working as slim to none. Funny thing, every PM in the room, even the head of the PMO, who has a background that includes Agile, thought that this was an appropriate methodology.

The kicker for me was when the head of the PMO stated that a successful project was one were estimated time was plus or minus 20%. A simple calculation told me that I was glad that I was not a PM responsible for a downstream project. If a resource is off by 20% on estimation of a large project, then my odds of getting the time I was promised from this resource is is low. Let’s say that the resource is committed to 160 hours of work on a project upstream of mine. This project can be successful even if this resource goes over 20% or 32 hours. If I only needed him for a week or two,  I certainly will not get the work I need or something else will need to slip. Add scope creep, poor requirements, etc and you have a very small likelihood of success, hence the CHAOS report results for project success.

Continue reading Chaos to Waterfall to Agile – The Evolution of Software Development