Last week I held my first meeting at NetDoktor, introducing the rest of the company to both what I’m doing and how I organize my work. Of course, I’d dropped the ‘agile’ word around the office from time to time and, suprisingly, most everyone had some idea of what it meant. Sure, it was some kind of new-fangled, black-magic to them, but they understood that it was supposed to help bring ideas faster to market. It was time to to shed some light on the subject of agile, and what better way than to walk them through the tool I use every day – Pivotal Tracker.
So, I setup a weekly ‘Sprint Planning’ meeting and sent out email invitations to the new project members in Tracker. Reactions were all over the board from “Dan, what is this you sent me?” to “hey, what’s the password?“. For now, I only gave product managment the capability to add and change stories.
What’s the difference between Stars and Cogs?
Since stars and cogs are such a great visual, this was the first question from the team. What’s the difference? I told them starred stories created real end-user value. Things that make the customer go “ooohhh and ahhhh” or their time on our site easier and more meaningful. Cogs were packages to make our day-to-day work easier or our servers’ lives a bit less stressful. Important stuff to be sure, but nothing directly visible for our users.
What are Points?
Next, I was asked about the points. I gave them a rough overview about how I estimate story complexity and its very loose relationship to effort. In turn, based on the work I had estimated and completed in the past, Pivotal Tracker automatically calculates a Velocity – or, more important for the team, a rough idea of how much work I should be able to deliver in the coming week. As “Cog” work wasn’t estimated (but certainly took time) they asked me how this effected my velocity. Great question, and one that’s seamlessly handled by the idea of estimating the work done over the past iterations and keeping focus on “Star” stories. Sure, cog work might peak and lull over time, but that’s why Tracker averages everything out.
I learned that presenting “Cog” stories is great for killing meetings. I lost three people within ten seconds of showing the Munin traffic graph of our eth1 interfaces after enabling mod_gzip. But it makes sense, if a story doesn’t drive our business forward who cares? Sure, we all take turns emptying the dishwasher and putting more toilet paper in the bathroom, but we damn sure don’t need to talk about this in a meeting!
I’ve explained to everyone that the Sprint Planning meeting is their opportunity for adding new stories and re-prioritizing the product backlog. During the week, only “the platform is on fire” type problems should interrupt our planned work. I’ll be sure and keep you updated as to how we progress.
5 thoughts on “Introducing Your Team to Agile Using Pivotal Tracker”
1. I don’t think that a Munin graph is appropriate for a non-technical audience. If you had created a bar graph showing monthly bandwidth usage and cost (before and after gzip), you wouldn’t have lost anyone. “We did X, and it’s going to save us $Y per month.” Anyone can understand that.
2. If by enabling gzip you mean enabling mod_gzip, that could greately improve page load times, depending on what kind of content you’re serving, and everyone loves fast page loads. Unless your pages don’t compress well, mod_gzip can definitely drive your business forward.
1. Absolutely right, Josh. We do need to discuss this, but in a way that’s business relevant. I failed to address my audience and but not presenting it would be failing to do my job!
2. Thanks for the catch – updated now in the post!
Thanks Matthias for your helpful posts about Agile Tools. We’ve just decided for using Pivotal Tracker in our distributed Rails dev team.
Just the import of our Excel-based product backlog was a bit tricky. This should be eased definitely.
I’d also check smartQ (http://www.getsmartQ.com). It’s not designed with only Agile in mind, but as a general Kanban board for any purposes.
Thanks for the post.
We in the Agile community agree that Scrum is a great simple light process. It has some very good ideas.
I used pivotal tracker with some success on a couple of projects.
As with anything else its important that a tool does not define a process but a tool assists a solid, proven process.
As an Scrum advocate and consultant for teams that use scrum or some form of it I think http://www.Scrumdo.com lends itself better to Scrum and general Agile principles.