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”
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”
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”