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”

Why I Don’t Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell

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”

What is Backlog Grooming and How Much Time Should I Invest?

What is Backlog Grooming? - Larry Apke
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?”

Trust and Agile

I had the wonderful opportunity to have a panel discussion recently regarding Agile. In my warped world, there is no greater pleasure than getting grilled on how Agile can be implemented in the real world. As such conversations are wont to do, a consistent theme emerged. In this particular conversation it was all about Trust.

If someone asked me to pick one word that could be used to describe a low functional Agile team versus a high functioning team, there are two words that come to mind – Discipline and Trust. Of these trust is probably the most important in that it can be hard to acquire, difficult to keep and easy to lose. As a scrum master, my team has to trust that I have their best interests in mind at all times, that the metrics I compile will never be used to punish them. They need to trust each other to be able to commit to a body of work for any particular sprint, etc.

Continue reading “Trust and Agile”

Agile as Religion

For the sake of full disclosure I am not a big fan of organized religion. I truly believe that each and every individual has their own needs when it comes to “spiritual” matters and there are many ways to achieve the basic human need to feel connected to our fellow humans and the universe as a whole. Perhaps this is what has me cautious about the state of Agile today in that it taking the appearances of a religion or cult. Like many religions the actual meaning behind the religion are lost and all that remains is a slavish flowing of fundamentalist dogma (words taken as literal truth) and ceremony. Agile says that we need to do this so we had better do this before someone calls us out as heathens.

One of the really irritating thing for me is when Agilistas talk wistfully about their brush with greatness as in I was at the Agile conference and actually touched the cloak of (enter your favorite Agile deity here). Hey, I can respect these guys, but they are like all humans fallible. They may have put forth some great ideas, but quoting a source by authority alone is a weak argument. To be an effective argument one must not only quote a chosen one, but also give evidence as to why this particular bit of wisdom is applicable to whatever context one finds oneself.

Continue reading “Agile as Religion”