Monthly Archives: September 2009

Eye on the Ball

It is a project management week for me on three fronts.

1. I’ll be teaching Gantt charts as well as Scrum burndown charts in the OOAD (Object-oriented Analysis and Design) class on Tuesday.

2. We are testing out Scrumy this week for SnupNow.

3. Our first pilot site is a project management consulting company, specializing in earned value. I hope to talk to them this week since our meeting last week was canceled.

While I was googling for tools that students could use for an assignment, I looked again for a Scrum tool that might work well for SnupNow. I tried out Planigle earlier and it did not feel like a good match, and I have alluded to our disastrous attempt integrating Agilo with trac. We have roughly 200 open tickets in trac (requirements, tasks, and bug-tracking software), with more than 500 closed tickets in that system. I would like to have something that integrates with trac. My second choice would be something I could migrate to from trac.

That might not be the ticket, however. So far, so good using Scrumy for a couple of days, except that we are duplicating data. Worse yet, I have no doubt that we have some information now in Scrumy that is not in trac, while we definitely have lots in trac that is not in scrumy…heavy sigh. There is not even a good place in scrumy to put the trac ticket number, although in some cases I tried to put it in the description of a story or task. At this point, I do not see a way to replace one with the other.

With it’s visual appeal (see my purposely blurry screenshot below), I think scrumy might help the team with our focus and productivity. I also like the connection of the requirements (stories) to the tasks, something we only do manually in trac, if at all. I decided to go for it and paid the few dollars for the pro version so I could password-protect the project.

Some SnupNow Stories and Tasks in Scrumy.com

Some SnupNow Stories and Tasks in Scrumy.com

I often decide what I will work on in a week, get those things in my sights and then tackle many other things, sometimes not getting done what I set out to do. This should be no surprise to anyone in this industry, not to mention to anyone who knows me.

I look forward to seeing the burndown chart. With many stories added during the week, I’m sure it will not look like it should. We can then work to improve that, with a visual that just might help us do so. Seeing the sprint start with a certain number of stories and increase over the course of the week as we all toss more into it, while also chunking down, knock on wood, might be a very helpful visual. Of course, since we are just starting out and did not do a real sprint planning session, it already shows. I’m thinking we might need to do 1 week sprints, as 1 month and 2-week iterations have not been highly successful, but this is what the burndown chart looks like right now.

Scrumy Burndown chart start, not yet doing it right

Scrumy Burndown chart start, not yet doing it right

I have tried doing a manual burndown chart, and that was just a ton of work from our ticket system. I’m also not ready to figure out how to customize and write our own burndown charts in trac, although I did initially write a burndown report that was less than satisfying.

A Subset of our Open Trac TicketsReport with Open Trac Tickets

To get from here to alpha delivery in January, I really need to get and stay focused, while also trying to provide whatever others on the team need in order to do the same. That is much harder to do while teaching on Tuesdays and Thursdays, of course. During the week, my brain can be all over the place right now. That isn’t good.

When I started dating my husband, I found myself participating in a very athletic family. In addition to the Thanksgiving football games (snow or no snow), they were having a family softball game. While I played tennis and table tennis, that was about it. There I was up to bat, petrified, knowing I sucked at this sport. His sister pitched to me. I swung and missed. My boyfriend called out “keep your eye on the ball.”

Holy revelation, batman! Although I guess I did that in tennis, this was a lightbulb moment for me. I thought “Hey, that just might work.” I watched the ball, swung, and connected. Really. That worked. My husband still laughs about how this whole “eye on the ball thing” was new to me.

With my mind all over the map right now, I need to focus, to keep my eye on the ball and hit a line drive. I know I want a home run, but it is a team effort. I need to get on base and when others do the same, we will make it around those bases. Scrumy, I hope you can help.

OK, Dawn, OK SnupNow team, keep your eye on the ball.

When to Bake Crackers, When to Mash them Up

Friend: Just try making something from scratch the next time you need to bring something. You might enjoy potlucks more if you don’t feel guilty for buying whatever it is.

Dawn: OK, I’ll give that a try and see what I think

(later)

Potluck coodinator: Dawn,why don’t you bring crackers and cheese on Saturday?

OK, so which one should I be making from scratch–the crackers or the cheese or both? Have you ever baked a cracker? I haven’t–at least not on purpose, and, frankly, I’m not about to try it right now, even if I could make¬†these ¬†http://daringtothrive.blogspot.com/2008/10/success-is-crispy-healthy-gluten-free.html or any of a number of other recipes. I’m just not the kind of girl who bakes her own crackers, and you can quote me on that. I’m OK with baking a cake with a mix.

I’m a believer in the division of labor. If someone else has made something that would work well for me, I would rather use that unless it is cost-prohibitive either initially or over time.

For example, I’m not going to write map software. We will use the google maps API like many a web site has done. I’m not sure what to do with the calendar, however. I wrote one homegrown calendar component for one read-only purpose so far, but we will need to start doing data entry via calendar too in the future.

We will have work to do with whatever calendar approach we use for our application. Our framework now has a schedule component that we can work with as part of the raw ingredients for baking our own. Google calendar is another option, if this would best be done with a mashup. It has a lot of features, with a good user interface. However, it might be best to minimize our external dependencies and avoid a mashup in this case.

Because this is not critical path before we go to alpha delivery, we have some time before we need to decide whether the data entry via a graphical calendar feature is a mashed up cracker or a piece of cake.