on hiatus

We wrapped up sprint 2 on June 20th and just had the review and reflection meetings yesterday. For those keeping score at home, that is a more than a 2-week gap. The process has improved considerably since last time and we were very close to hitting our targets. We came through with 3/4 deliverables and are close to the other one.

So why the long haitus? Again, we can't work around missing pieces of the puzzle; and instead have been waiting for them to appear. At this point there is simply no more prep work to do.

Until we reach a point where circumstances and priorities are not changing faster than the sprint length, all future sprints are on hold. Otherwise we spend too much time re-planning and it is not productive enough. I hope to be writing again very soon - it seems the missing pieces will arrive this week!

I made alot of mistakes

The title is from the Surjan Stevens song Chicago, if you haven't heard it before I would recommend it.

This sprint I decided that I needed to get a ton of things done because I was behind. I would not be slowed down by things like history or logic... Claudia even warned me that too much of the work was for me, but I still thought I could power through it. Funny thing is, the time-space continuum did not expand for me. Instead of being only a few hours behind with 4 days left to go, we are over 25 hours behind. Indeed, I made a lot of mistakes.

First, the planning meeting was over Skype and using Agilo software. This was the first time and things were unfamiliar. I got a little frazzled looking for things. To save time, we broke out the tasks for our own stories separately - tasks were even less everybody. Also estimating time was almost independent. Lesson = always know your meeting software.

The rest of the mistakes were technical or stubborn. Equally problematic, but easier to avoid and less interesting to discuss...

There is no everybody in task

As far as I can tell, one of the basic tenants of agile work is that tasks should be time-boxed, complete (clear goal to finish), understandable, and everybody can do them. The first three requirements are already no picnic but we are learning. The 4th one is proving to be a bear.

The tasks are very obviously either for me or for Claudia. This makes the burn-down of limited use. If she sees that I am behind she usually cannot help and vice versa. It is partially due to our unique (sometimes non-overlapping) skill sets and partially due to geographic location (access to equipment).

I am not sure what adjustments to make here...

Proof of Concept

Ok, after a retrospective meeting and a meeting with the boss - I am ready to chalk up Sprint 1 to proof of concept. Not necessarily proof that the concept works perfectly, but it is on the right track. The good news is that he is willing to get more involved and provide the necessary insight as product owner. Bad news is that a combination of factors (illness, travel, national holidays) put a 2 week (one full sprint length) gap between our finale/retrospective meeting and today's planning meeting. Hopefully in all that time we subconsciously learned something and can plan better now. Meeting in T-53 minutes...

Initial Sprint completed?

Technically yes, but what does it mean? It was exciting to chip away at smaller problems and see progress but we did not quite pull it off. We had a really productive first day, largely due to things we had  

accomplished before the sprint officially started. We did complete more than half of our tasks (~50 hours) but were too slow. We closed 2 of 5 stories with 2, 10.5, and 5 hours left on the open stories.  

What happened? Did I do enough as scrum master? Did I pull my weight as a team member? I don't know...

This sprint illustrated clearly that assuming three roles is not ideal. We did our best but did not see all the cards on the table. Barriers appeared that we could not work around, e.g. planning for the wrong neurophysiology software.

Besides more knowledge, one disturbing issue is almost. We completed over 70% of tasks and almost finished the stories. This means the stories are incomplete. This was one my problems I hoped to overcome - always working a little more to finish instead of getting things done. I hope future sprints have less external shenanigans and produce more concrete results.

14:31

Yesterday's 5 minute tag-up took 14 minutes and 31 seconds - all is not smooth and research-land. It exposes a problem of no real time for team interaction besides the tag-up and emails. The more disruptive problem is planning around holidays (I have had ~1 holiday per week recently). One person on holiday in a two person team = no meeting. I have still called in, but have no work to report and can take no action as scrum master so there is little sense. We should have planned around them... next time Gadget, next time!

Short sprints + small teams + holidays = problems. 

Marco... Marco?

Our tag-ups are tricky enough with a 6 hour time difference - my day is more than half way finished by the time I report what I will do today. But a friend was giving his PhD defense, so we agreed to cancel yesterday's meeting. No big deal, small team, good software to track progress. We would catch up on everything today.

I had to travel to Geneva today to meet a clinician in the project. Very interesting, real nice guy, good meeting... got in the cab to the train station and saw my watch. I totally forgot the time and was late for the tag-up call. No problem, it is not too expensive to use the cell... of course I don't have the number.

Luckily there is wifi at the station and I fire up skype on my iPod Touch. I was 90 mins late for the meeting but fortunately the rest of the team was really cool about the whole thing. I can't drop the ball again...

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!