It Shall Be Released
A development team I used to manage had a custom for your first project. It was to write your name in a comment in a text file, get it reviewed, and deploy it to production. The file had been around for a long time and contained lots of names from back when senior developers were interns, and it even contained a few names more than once—for people who left the team and then came back. A lot of team members thought it was kind of a silly first assignment, but it was both a good learning experience to understand how code went from your desktop to live, and it was a good way to get people started. Being able to ship something, even as small as one line in a throwaway file, broke a lot of initial barriers that new people face. Near the top of everyone’s launch plan was to complete this minor task, and most everyone commented on how valuable it was for later.
Three of the original 12 Agile Manifesto principles focus on the importance of delivery. There is a reason for this: projects that spend too long not delivering value run the risk of growing stale, or worse, not growing at all. Teams can get accustomed to not delivering, and instead be in a constant state of being close to ready, but not quite ready enough. The team can also shift their focus on rewriting components that haven’t been shown to customers or attempting to improve products that haven’t yet shown any customer
Please log in or sign up below to read the rest of the article.