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 doubt there are many people in this world who have the passion or spend more time researching about Agile than I do. Over the years I have seen many sacred Agile/Scrum cows questioned. Usually when one has the guts to do so there are scores of Agilistas ready to denounce anything that goes against their indoctrinated Agile/Scrum education. It seems that many fail to understand that in order to prove the value of something, it must always be questioned. Hell, the whole damn thing started because a few folks decided they would question orthodoxy and find better ways to do things.
And now I think I have found the very last sacred cow remaining. Over the past few weeks, whenever I have some spare moments, I have googled, binged and read blog after blog. My search – is there anyone else out there who really doesn’t care for Agile/Scrum whiteboards. I can say from experience that it appears unanimous. Every person talking about Agile or doing Agile absolutely, positively, without question loves Agile whiteboards to track iterations. All that is except me. Yet I cannot hold my tongue any longer. I know I will go to Scrum hell, but I have always had a strong distaste for Agile boards.
Continue reading Why I Don't Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell
After my experience working with dozens of scrum teams in transitioning to Agile, I am thoroughly convinced that a great deal of Agile success is wrapped up in the two things that most lower functioning teams do not do well – Release Planning and Backlog Grooming.
So what is backlog grooming?
Personally, I do not like the words “backlog grooming.” To me it is merely an extension of sprint planning so forgive me when I refer to this as extended sprint planning. I think one of the things that early Scrum made a mistake on is that it expected sprint planning to happen the very first day of the sprint in what for many are LONG planning sessions. In fact, I would not be surprised if the term backlog grooming was coined so that early Agilites could save face!
In other words, let’s call this something other than sprint planning so we don’t have to admit we were not 100% right on what sprint planning should be. (Given the religious nature of Agile and Scrum I fully expect to be excommunicated and eviscerated so please feel free to comment).
Continue reading What is Backlog Grooming and How Much Time Should I Invest?
When in doubt, google. I found the definition for leadership from about.com – “Leadership, a critical management skill, is the ability to motivate a group of people toward a common goal.”
I would guess that this definition is innocuous enough, but I just can’t seem to completely agree. I know that a lot of people think that leaders are great motivators. While this may be one of the by-products of leadership, I have always maintained that great leaders do not motivate others but create the environment whereby self-motivated people will be able to flourish.
Continue reading Thoughts on Leadership