Note: This is the second article in a 2 part series. To read the first article, click here.
To officially wrap up this project I held a “release retro” with the individuals involved. It was no different than a regular sprint retro, it merely covered a longer period of time.
Here are the lessons learned from this retro:
- Communication was excellent: The “dev team/contractor” stated that there was never an issue with unclear requirements and it was easy to ask questions.
- Setup increased focus: because I was the product owner/scrum master, I had to deal with the requests/issues from the stakeholders. As a result, the contractor was able to focus entirely on construction and not worry about non-construction issues (requirements, “he said, she said”, etc).
- Self-organizing happened naturally: The contractor expressed an appreciation for our “hands-off” approach to his work. Because I was busy with the stakeholders on determining future work, I was unable to micromanage the contractor. I only had time to push work into the sprint and explain to the contractor its purpose, then it was up to him to determine a solution. While I consider myself a micromanager, Scrum’s iterative approach kept me busy with relevant things that I had no time to micromanage.
- Construction works differently than software development: In software development, focus is placed on doing the work for one feature before doing the work for another feature. For this project, I divided the remodel into three sections and tried getting each section completed before moving to the next one. The contractor let me know that it was easier to do one type of work across the sections before moving on (i.e. do electrical work for three sections at once instead of doing one section at a time). Even though we were unable to deliver value for each section as it was finished, it was the nature of the job.
- It is easier to work against a defined deadline date. The iterative approach we took had many advantages, but one thing lacking was the motivation to finish sooner. Leaving the project open ended did not pressure us to finish faster. One person suggested that next time we create a range of dates that reflected a realistic expectation of when the project would be finished.
Here is how the retro revealed the importance of a ScrumMaster:
- Initial creation of tasks faltered as the project progressed: The initial excitement of practicing Scrum led me to create a backlog with many stories. As time progressed, I became less likely to create tasks on paper and settled with remembering them in my head. This led to slight confusion later on as we had to figure out the last decision we made on a story. A separate ScrumMaster would have helped me keep track of stories on a board.
- Contractor faced impediments during sprints that led to delays: During certain weeks, there was some information that the contractor needed to continue that I had not communicated. I thought I had made it clear, but I was wrong. In other instances, work had to be pushed into the next sprint because of simple issues. A ScrumMaster would have been focused on removing impediments during the project, potentially finishing the project much earlier.