Have you ever used Scrum outside of technology? I was given the opportunity to use Scrum for a project to finish remodeling a balcony. The first phase of the project was a major remodel, the second phase involved moving audio/video equipment to accommodate people entering/exiting without disturbing the operator. The current setup had exposed cords (tripping hazards) laying around and affected access to the balcony. To solve these problems, I used Scrum since I have personally benefitted from it at work.
Here is how I implemented Scrum roles:
- Stakeholder – my friend who used the audio/video equipment
- Dev Team – contractor hired to work on project (yes, one person)
- Product Owner – Me
- Scrum Master – Me, but only partially (I will explain this in a future post)
Here is how I used Scrum ceremonies in this project:
- Sprints – Lasted one week, since we had to setup and take down audio/video equipment each weekend. Work not completed in a week was pushed to the following week.
- Sprint Planning – On Sundays I called the contractor and asked for estimates regarding tasks at the top of the backlog. After the call, I sent out an email with a prioritized list of tasks to be worked on that week.
- Sprint Review – On Fridays I came in and saw what the contractor finished (Demo).
- Sprint Retro – On Fridays I called the contractor and asked the three retro questions to improve the following sprint.
- Backlog Refinement Meetings – I periodically met with the stakeholder to gather details and prioritize the backlog.
We finished this project in twelve weeks. This sounds like a long time for the amount of work involved, but here is how we benefitted by using Scrum in construction:
- Better Communication: Weekly calls ensured that the contractor only worked on what was important. As the project progressed calls became shorter as our mutual understanding of the project grew.
- The final product did not match initial ideas: Because we took an iterative approach to this project, we found that some of our earlier ideas would not have met our actual needs. Iterative construction allowed us to adjust our initial ideas as we became more aware of project.
- Making decisions at the last possible minute prevented refactoring: We did not put work in the sprint until just before it was necessary to be done. This approach
- Saved time for the contractor – he did not build something that was not asked for, except one time,
- Saved money – contractor did not have to bill for redoing work,
- Made fixing mistakes easier -most of our mistakes were minimal because of prior research, and
- Prevented major blunders – in phase one of the project, the contractor built something that did not fit the requirements, resulting in a major refactor and migraine.
By applying the principles of Agile to this project, I was able to reap the above benefits. We avoided the headaches that resulted from phase one of the project, where major work was redone due to improper research and requirements gathering. That being said, it was not a perfect implementation. The mistakes made and lessons learned require a separate post, and in my next one I will share with you how I learned the importance of Scrum Masters.