False Starts

Since my team is separated by the Atlantic Ocean, we needed a software solution to still work together. I decided on the Agilo plugin for Trac. After all of the planning meetings, I had two days to get the software up & running and backlogs filled in before I left the country for a conference. I also had to give a research talk and finishing a poster - what could go wrong?

Agilo is really good software, but I was really bad at setting up the initial repository. Unfortunately the IT expert that did this for me before was on holiday. The project was not set up before I left. I came home late Sunday night and was on a train to Pisa all day Monday hoping I might be able to set up the project Monday night.

This was not to be. The internet was down Monday night when I finally arrived. No big deal, I still have the 6 hour time change working for me, I can just hit it in the morning... until the internet was out at my lab all day Tuesday. Awesome! I can't even set up the site, much less fill out the project or sprint backlogs, until Thursday afternoon (4 days into a 10 day sprint).

Luckily the recording hardware was fubar and I couldn't do any of my tasks. So my team decided to start the sprint a week late (today). It is cheating and will inflate our real velocity because we had an extra week (sort of) to do the work. But neither one of us wanted to waste time back-dating tasks or having another planning meeting before anything was actually accomplished. 

The First Sprint

Enough research, enough thinking, I need to just start. The only way I could ever learn is by making mistakes, right? It still didn't make things much easier, but I needed to start being the Decider.

Since the team is small, we went with two week sprints and short meetings: 1 hour planning, 5 minute tag-ups, 1 hour post-op, and 1 hour reflection. I am still not comfortable bringing in the boss (product owner) so I decided that my team would also fill that role. We added a meeting to decide what are the most important scientific questions we could feasibly tackle? It gives the student more control over her masters but also leaves the door open for the real boss later.

We labeled research questions as User Stories, e.g. Characterize neurophysiology equipment or Implement an inverted pendulum model. After an hour, we had enough stories for 2-3 sprints so we called it a day.    

Two days later was the planning meeting where we decided how many stories to tackle, and what tasks each of those stories would need. After 30 mins the whiteboard was full and we started estimating task timeboxes. Within 10 mins everything was assigned and we were under committed (i.e. less work to do than working hours). Either we had been very optimistic or had forgotten tasks.

 The first meeting exposed a few pit-falls we would need to avoid. 

• Tasks could not be picked up by anyone. The student and equipment were in the USA, I am in Switzerland.
  
• I had 90 mins available to work on this project each day. I added short tasks just to have something to say at tag-ups. Those tasks were less relevant.
  

Problem 2 was fixed when I remembered other areas of this project I need to produce results for, but that only exacerbates problem 1. I have a conference next week and then the sprint starts next Monday - lets see how it goes...

Changing the Game Plan

Grüzie World,

My name is Jack and I recently earned a PhD in biomedical engineering. Now I have evolved into a post-doc and suddenly am a project manager. Honestly, I had no idea what to do. I took the road of many PhD students and proceeded to do a ton of planning and research without any actual results. Then I thought back to my own research experience.

I worked in an exciting lab with two friends also pursuing degrees and had two fantastic advisors. I worked on a topic (brain-machine interfaces) I am passionate about. Our research was successful. Despite all those good things, I was always behind and working constantly. There had to be a better way.

Wikipedia explained traditional project management to me and I was intrigued. What could be easier than following a plan every day? Would I have time to make these plans? No. Could I predict well enough to plan long term? No. If 80% of research fails, there doesn't seem to be any point in long-term planning...

The other option was Agile project management, specifically Scrum. It is adaptive and always produces the most valuable results at any particular time. But it is rooted in software development and wasn't a clean fit (newer article on Agile App development). I had a large team of >20 and a small team of 2 (ideal team size ~7). Both teams have members on different continents (ideal team co-located). I also play many roles in both teams and am typically limited in time and/or influence. This could never work...

I turned to a good friend who had explained Agile to me years ago. We talked about his experiences and my goals. He told me not to follow the letter of the law, but to focus on the spirit. So with a supportive boss, expert counsel, and most importantly a bright and enthusiastic student the experiment in Agile Research begins!