Archive for the ‘Management’ Category

Story Points vs. “Ideal Days”

July 29, 2010 Leave a comment

I like to think of myself as being pretty anti-dogma when it comes to Agile methodologies. I think one of the most common ways that a team can “fail” in their adoption of Agile is to become fixated on strictly following what is and isn’t “Agile”.

One topic that has come up repeatedly for me lately is the choice between using Story Points for sizing stories in our backlog versus using “Ideal developer days”. On this topic, I have a very strong opinion, possibly bordering on “being that Agile-Nazi guy”, but I stand by it.

There are a number of ways that Scrum teams can size the items in their backlog. To be clear here, we’re talking about relative sizing – something you’d do in a release planning or backlog grooming type of meeting – as opposed to iteration planning, where you’d be tasking out a story, typically in hours. Some teams use t-shirt sizes, some teams use arbitrary “story points” (which have no units), etc. Other teams use “ideal days”. The teams I have been on lately fall into this camp. I have issues with this.

Units of time, and the associated baggage
One of the problems with sizing stories in ideal days is that we’ve become so accustomed to estimating our tasks (and being held accountable for them) in units of time, that I think we tend to slip into that typical dev mindset where we immediately switch into task estimating mode. If we’re not careful, the release planning meeting can become a tasking meeting. Related to this, though I have no evidence to back this up – I think there is a certain level of baggage that comes along with estimating in units of time. When you’ve been burned by a bad estimate, it’s easy to estimate based on the size of the ass that needs covering rather than the size of the actual story.

Mike Cohn’s “Agile Estimating and Planning” has an entire chapter dedicated to the debate over points vs. days. Cohn discusses some excellent reasons why a pure points-based approach is preferable.

Whole-team Estimates
Agile teams are often cross-functional. On my team we have, in addition to 3 developers, a QA, an interaction designer, and a visual designer. Now I’m not suggesting that the estimates won’t be driven by the developers most of the time, but there are a couple of reasons why including the rest of the team in the estimation process is helpful. First of all, it builds a more cohesive team – sizing things in “developer days” seems to imply that other people don’t have anything in particular to contribute to the process. Secondly, and potentially more importantly, you may miss out on crucial feedback from the other members of the team. A feature may be relatively easy for a developer to implement, but may take a QA a large amount of effort to properly test.

Points-based estimates don’t decay
I think this is one of the biggest reasons to go with a points based system. By saying that points-based estimates don’t decay, we are saying that for the most part, sizing estimates based on points don’t change over time. The major result of this is that your velocity will continue to be a meaningful measure of your team’s ability to deliver. It’s probably best to illustrate this by way of an example.

Suppose you have two teams that are essentially identical. Identical in size and ability. Their backlogs are also identical. Team A uses an ideal days approach to sizing their stories. Team B uses non-time-based story points.

Both teams start off their project with the same number of stories scheduled, and both teams manage to successfully deliver on their commitments.

Fast forward to a few sprints from now. Both teams have improved on their ability to deliver. Perhaps they are working with a new technology or architecture that takes some time to get fully comfortable with. Or it could be increased productivity through the use of new tools. Or perhaps it’s just a result of the team learning to work better together.

Compare the velocities of the two teams. Despite the fact that both teams have improved their ability to deliver (as measured by their velocities), Team B’s improvement is much more easy to see. The shifting of the scales of measurement for the team using ideal days makes the velocity measurement a much less useful measure.

Categories: Agile, Management

On the importance of progress

March 10, 2010 Leave a comment

Well it certainly has been a busy month (ok, over a month) since my last post. New project went live, the Vancouver 2010 Winter Olympics – and to top it all off, a new full time position. It was definitely nice to have a little down time to do some reading and thinking.

I recently read an article on HBR outlining a list of “10 Breakthrough Ideas for 2010” (subscription required for the full article, but you’ll get the gist of it from the sample). On the topic of “What Really Motivates Workers”, the authors discussed the results of a multi-year study where they tracked the day-to-day motivation levels of knowledge workers. The findings, while potentially surprising to leaders and managers shouldn’t be that surprising to most knowledge workers. Whereas a survey of leaders and managers identified “Recognition of good work” as the number one factor for motivating workers, the survey of the actual workers showed that the factor that had the biggest (positive) influence on workers’ emotional state was this: “Progress”.

On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.

Call it apophenia, but as always, I seem to find a way to relate things to each other – in this case, Agile software development.

Technical Practices (i.e. “stuff that devs do”)

In a recent interview (actually the first technical interview for my current position), I was asked: “What do you like about TDD?”. I can’t recall the exact words I used, but I said something along the lines of:

I enjoy the rhythm, the groove you get into when you’re writing a few lines of test code, watching it fail, writing your code, watching it pass. The rhythm of Red, Green, Refactor is very satisfying

How does this relate to “progress”? Well when I do TDD, typically I work to implement the smallest bit of functionality I possibly can. I might implement the “happy path” on my first pass, an edge case next pass, an error case after that, etc. Depending on the complexity of what I’m implementing, I’ll go through the Red, Green, Refactor cycle every 5-10 minutes. Every time I go from Red to Green – that’s progress. Every time I refactor my code and the tests pass – that’s progress. Every time I check in my code, the continuous integration build runs, incorporating changes from the rest of the team, all the tests run – that’s progress.

Contrast this to the “other way”. I spend a few hours writing. I might do some testing by clicking around the application – seems to be working. A day later, another developer pulls down the source code – it won’t build. You have to go back and try to figure out what happened. That’s *not* progress. So we eventually fix the code so that it builds. A week later (if you’re lucky), the QA is doing some manual testing on the application – the application blows up due to an unhandled exception. Now you have to think back to what you did a week ago. That’s *not* progress.

You get the idea.

Team-level Practices (i.e. “stuff the entire team is supposed to do”)

One of the (in my mind) more important things Agile teams need to do when planning their iterations is defining what it means to be “done”. “Done” means we have met the acceptance criteria (which means that you have to first define them). “Done” means that when you’re done with a user story or feature, it’s shippable. It doesn’t require “tidying up” later. It doesn’t require a “stabilization phase”. It’s done and you don’t come back to it. If the customer wants to change something, well that’s another story – something be prioritized and scheduled just like any other story. But at the end of that iteration, it’s shippable – no “If”s, “and”s or “but”s.

In other words, the team is always making forward progress. Now, of course, if the client keeps requesting changes that’s not forward progress and quite rightly would be demotivating to a team (“I want that button green….now I want it blue….now I want it red…”). My personal hunch about this is that by requiring the customer to place the change request and prioritize their other requirements around these changes will eventually change behaviour simply by calling attention to the requirements churn.

“Working software over comprehensive documentation”

The preference in Agile methodologies for working software over documentation (note the wording: “working software over documentation” – doesn’t mean you never do documentation) – is another nod to the importance of progress. Few people regard spending months and months doing big up-front analysis design, writing reams and reams of documentation, “progress”. Shippable software – working software – is progress.

The “Progress lens”

So next time you’re feeling really positive (at work or in life in general) – think about what you’re doing through the “progress” lens. Maybe you’ve fixed a bug that’s been…erm…bugging you for a coupe of days. Or you’ve finally got your head wrapped around an idea that you’ve had trouble grasping. Or you’ve just run a new personal best 10k – not a world-class time by any stretch of the imagination, but a personal best nonetheless. Or maybe today was just a little bit less crappy than yesterday – that’s still progress.

Categories: Agile, Management Tags: , ,

Toyota in crisis and the merits of navel-gazing

December 22, 2009 Leave a comment

I caught this article today on Twitter which looks at some of the reasons for Toyota’s current financial state (two consecutive years of reported losses after half a century of outstanding performance).

The article is a really interesting read. But you only have to read the first paragraph to get to the part that really stuck out in my mind.

Shoichiro Toyoda, the 84-year-old family patriarch and honorary chairman of Toyota Motors, responded to this by announcing a stunning shake-up of top management. He chastised top managers for losing sight of the fundamentals that had made the company so outstanding and promised that the company would “return to basics.” The company’s financial reversal occurred, he indicated, not primarily because of the recession’s severity, but because after 2000 the company’s top executives made the mistake of pursuing finance-driven growth and pricing at the cost of sacrificing the basic principles that had made Toyota thrive.

In a situation where many leaders would look outward to explain their organization’s situation, Toyoda looks inward. “Here’s what we’re doing wrong”. “Here’s what we can do better”.

This is not to say that an organization’s situation isn’t to some extent a result of external factors – it isn’t a closed system. And it’s not to say that an organization should just shrug off the external factors – part of responsible management is to be aware of the external factors that might impact your organization’s success and, to whatever extent possible, manage these factors. But realistically you can only have so much leverage over these external factors. Internal factors, on the other hand, you do have control over (or should have control over).

Just from personal experience I also tend to think that the inward looking, reflective mindset tends to be much more compatible with the “learning mindset”. After all, if the reasons for my situation are “out there”, where I have little or no control, there’s not much I can do about it, and therefore not much motivation to look for more answers. On the other hand, if the answer is “in here”, where I do have control and can do something about it, I’m much more likely to keep thinking and learning until I find a solution.