All articles about Scrum

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

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?

It's the Discipline Stupid

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

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

Measuring Agile Progress – Not Losing Sight of the Big Picture

Agile, while light on “metrics,” does have some artifacts that are used to help track progress. Burndown and Burnup charts are extremely helpful in measuring sprint progress and helping to correct course. Capacity and velocity measurements are great at helping us determine how and what to plan for a sprint and a release. These are important measures in determining if we are going to deliver working software on a regular basis, but I don’t think they tell the whole story. In order to measure how far we have come (and how far we may still need to go), I have come up with another method of measuring progress, the Agile Principles survey.

In 2001, the Agile Manifesto and Agile Principles was ratified and published. It is these principles that form the basis of Agile, no matter what methodology you choose to implement. To me this is the big picture. We may (or may not) complete all stories in a sprint, we may (or may not) find a consistent velocity, etc., but if we do not do well at following the overriding principles can we say that we are truly Agile? Maybe, maybe not, but I doubt we could call ourselves Agile “mature.” In the end, we are all a bunch of scrum butts and Agility is not binary. Agility is a continuum. Just because we are used to thinking in terms of black and white and 1s and 0s, does not mean that the world (or Agile) falls into our neat little categories. It irks me to no end when someone tells me that a team is not Agile. Every team is Agile, but it is a matter of degree. No team is 0% and no team is 100%.

Continue reading Measuring Agile Progress – Not Losing Sight of the Big Picture

Using Individual Burndowns

I have my very own Scrum team right at home. There are seven of us in the family. I love each and every one of my family members equally, but that does not mean that each one of my family members is the same nor would I treat each one exactly the same. Of my three boys, each has their own wants, needs and desires that I need to help fulfill on a regular basis. One needs extra help for their homework, one needs extra time to help them with their driving lessons and my youngest just needs me to spend as much time as possible with him even if we don’t do much of anything (though we always seem to have something). In other words, in order to have a highly functioning family (team) I have to treat each family member (team member) a little differently. I don’t hand the car keys over to my five year old nor do I hold hands when I walk down the street with my twenty year old.

I have two second families right now, the two scrum teams that I have the pleasure of being acting scrum master for. Like my own family at home, both of these teams is comprised of individuals with different levels of Agile maturity. One team is close to highly functioning while the other is just now taking the first tentative steps into Agile. One team can handle nearly all their sprint planning while the other needs a great deal of time. One has tasks assigned to the team (and chooses tasks based on availability during the sprint) while the other goes through the effort of making sure that tasks are chosen during planning to ensure that they don’t over-commit.

Continue reading Using Individual Burndowns

Attack of the Agilistas

As someone who has been operated as a day-to-day scrum master for over five years, I have had the pleasure of working with over a hundred people in a Scrum setting. Their prior knowledge about Agile and Scrum ran the gamut from those who had never heard of Agile or Scrum to those who have been a part of a team at an existing place of employment. If I had to pick which I would rather have on my team, I would choose the complete novice every time.

Reading in bed one night a wonderful book called The Invisible Gorilla and Other Ways Our Intuition Deceives Us. One of the interesting facts that was presented involved the fact that people who exhibit confidence in their knowledge are usually the least knowledgeable. In other words, true experts are more likely to not have a high degree of confidence in their assertions. I think that this is because the true expert realizes complexities that someone with just a little bit of knowledge would not even know they do not know. In my experience, nowhere is this more apparent than with people who have had some prior experience with Agile.

Continue reading Attack of the Agilistas