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”
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”
I spend a good deal of time trying to make myself a better Scrum Master (see blog). This means reading lots of books, a great deal of googling and reading many blogs. Recently I ran into one called Coding Horror by Jeff Atwood.
He had a great entry about Discipline in software development.
I had the same conversation with a colleague of mine years ago when I was first introduced to Agile development. My argument went something like this. Left to their own devices, software developers are a fairly undisciplined lot. Every methodology of the last 40 years or so are merely a response from management to attempt to bring some order and discipline to software developers (and by extension software development). I joked with him that I should come up with the next fad, called disciplined development, throw a few buzzwords and ceremonies into it and then I could make a killing as a consultant. I mean isn’t that what every methodology fad has been so far?
Continue reading “It’s the Discipline Stupid”