Goals
This was it! The final stretch. For the last two weeks, we focused on wrapping up the project and training the end user, our client. Our goals were the following:
- Train the client
- Ensure the client is satisfied with the system
- Transfer ownership of the system to the client
Before we could sit down and train our client, we had a little prep to do. We agreed to take the first week of the sprint to implement the system, and then we would meet with the client the second week for training.
Permissions
The first issue to tackle was setting permissions on the Google Suite databases. We needed to make sure our client and whoever she chose could edit the databases, but the outside world would only have read access. Lucky for us, this functionality is built into the Google products we used. Indeed, the permissions were part of the reason I chose to use the Google Suite as a Product Owner.
It was simple enough to give our client the necessary permissions. We chose to require her to edit the databases from an account other than the admin account we created. This helps prevent issues such as permanent deletion. The admin account should only be used in an emergency.
Movin’ Out
Our team had developed most of the system under our own personal accounts. This meant we were the owners of all the content. Consequentially, this would impact the theater if one of us ever decided to delete our personal accounts. To avoid issues like accidental deletion, we transferred ownership from our accounts to the admin account we made for the theater. This would allow the theater full control over the content. This was a little tricky to do on the Google platform, but we sorted it out.
Backup and Versioning Control
“I want to be able to set it on fire and have it still work.”
-Costume Coordinator
Our client made it clear that she was worried the system might accidentally be wiped clean by herself or another volunteer. Christina and Silvia set out to ensure that our system was bullet proof. They spoke with Google representatives and found that even if every single file were deleted, a Google support rep would be able to restore the system.
Christina and Silvia also found that Google products keep a running version history of every document. This meant that if someone made unwanted changes, the files could easily be set back to a previous state.
Training
With our implementation finished and a few quick changes in place, we were ready to train our client. The Scrum Team and our client met in the usual spot in the theater. We huddled around a laptop and let our client run wild. We loosely directed her through the system, but allowed her to make every action herself. She caught on very quickly and liked how everything worked. Training was a success!
Scrum Highlight – Increment
Perhaps the largest difference between Scrum and traditional software development methodologies, such as Waterfall, is the product increment. The increment is defined as everything finished at the end of the current sprint, plus everything that was finished before.
In a traditional software development methodology, the complete product is delivered at the end. In Scrum, the product is consistently iterated on. This means that at the end of every sprint, the increment should be in a releasable state. The Product Owner doesn’t have to release the product, but they could if they wanted to! That is a key advantage of Scrum. Even if the project is cancelled halfway through, the stakeholders should at least have something to show for it.
Sprint Review
Because we had just met with the client for training a few days before, the Sprint Review was rather brief. We recapped the accomplishments for the sprint and prompted the client for any last questions. Our client said she was happy with the product and had no further changes.
Sprint Retrospective
For our final Sprint Retrospective, Andrew chose the Loved, Learned, Lacked, and Longed for exercise. This seemed appropriate for our final retro.
The two themes we loved most were working together as a team and getting to work with a client on a real issue. Many of the team members reported learning more about the Google platform capabilities and how to be Agile. Almost everyone said they what the project lacked most was time. Finally, the team longed for more coding and technical exposure. The Google platform was appropriate for the client’s needs, but the team agreed that it would have been more fun to work with true databases and a fully-featured dev environment.
Mitchell Milestone
I was delighted with how well the implementation and training went. I think we were very lucky to have a cooperative and willing client. Our client learned fast and let the dev team make most of the calls. This certainly made our job easy, and I sincerely hope she is satisfied with our product.
At the retro, I shared the feelings with my other group mates in wishing we had more time and resources to make the project even better. I admittedly feel guilty, as many of my group mates wished they had more of a chance to code, and I had done most of what little coding there was on this project. I didn’t realize until the retro that everyone was so interested in the scripting. In hindsight, I wish I had involved more people in the coding sections. Something I should I should work on improving is my ability to challenge others and give up some of the tougher assignments myself.
The project is over, but there is still plenty to discuss. Read on for the S(cr)ummary!
ACC 362 Individual Project 