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!