I Lied! I went to bed after my Tuesday post so I’m writing my Wednesday post now.
Wednesday, May 14
EIP stands for Employee Involvement Program and it’s the main project for the software development boot camp I’m in. The basic Idea is to create a web site where Improving Enterprises employees can log time spent on projects and have it sent to quick books automatically. The site will also be used to allow management to track who has and hasn’t logged time and how often they’re doing it. We started our first (mini-)sprint by generating a product backlog made up of whatever user stories we could think of. We then planned our sprint, which I don’t think went very well. We ended up cranking out a bunch of different tasks somewhat independently because we had a pretty small time box. This isn’t bad on its own; the problem was that we didn’t take time to make sure that we all knew what each task was. We weren’t staying on the same page (this has been a problem for us before).
The first “day” was about an hour. We split up into three pairs, and each took a task and got to work. Well, we tried to anyway. We quickly learned that there was some setup we needed to do before any of us started working independently. After that, we realized that because all of the tasks were related to time entry we needed to get that set up before we worked on anything else. So we split time entry up into three parts and my partner and I got to work. This part was easy enough; we just created a few tests to make sure our properties weren’t null and stubbed out and wrote the code from there.
The second “day” (also about an hour) got a little rough for me. After we finished our first task I started to look at the others on the board. Several of them had something to do with time and clocks, but because I wasn’t a part of the conversation that generated those tasks I didn’t know what to do with them exactly. Unfortunately the others were in the middle of their tasks so I couldn’t really ask them about the time tasks. My partner and I got to work anyway managed to generate some tested and working code (I was still a little frustrated because of not knowing the end goal of our task).
DAY 3: WALL OF GIT. At some point early in day 3 I attempted to push our build to the teams Github repository. Pushing involves rebasing, and that can cause a merge conflict. It turns out that none of us were set up to deal with a merge conflict. We started trying to configure git to use Visual Studio’s merge tool, but it took the entire “day.” Jef and I managed to get mine working just in time for the sprint review and retrospective. The consensus of the retrospective seemed to be that we need to work on how we generate tasks (and do some modeling to help with that). After Jef left the team played around with Git a bit in order to better understand pushing, pulling, commits, and merge conflicts (We also wanted to make sure it worked for all of us).
Hopefully (Mini-)Sprint 2: Electric Boogaloo will go a little better.
Some Thoughts on Overthinking 
Beautiful, absolutely beautiful!!!! I love that you learned this so early!
I see so many teams who struggle for months and don’t get that this does not work. What did your team do to change this for future sprints?
“We ended up cranking out a bunch of different tasks somewhat independently because we had a pretty small time box. This isn’t bad on its own; the problem was that we didn’t take time to make sure that we all knew what each task was. We weren’t staying on the same page (this has been a problem for us before)…but because I wasn’t a part of the conversation that generated those tasks I didn’t know what to do with them exactly. Unfortunately the others were in the middle of their tasks so I couldn’t really ask them about the time tasks. My partner and I got to work anyway managed to generate some tested and working code (I was still a little frustrated because of not knowing the end goal of our task).”