We advocate the waterfall method of project development in order to launch a website. Get it up and running so that revenue is coming in the door. Then, we apply Agile methodology to the details and functionality of the site. When we go into an Agile project, we operate in what are known as code sprints, which is a way of saying that we are working with an undefined set of deliverables. 
Massive projects have these undefined deliverables early on in the process, because the end result is so obtuse. We know that we are building a website, and people need to log into that website to create a profile; but that is all the information that we need to start with. We need to take small steps to get to the end result. To manage those small steps, we hold a daily Scrum.
Generally speaking, Scrum is a way for Agile development teams to work together to develop a product. The goal is to get everybody on the same page, in order to maximize the deliverables in each iteration of the project. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.
More specifically, Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their attention on solving what might otherwise be an insurmountable challenge.
There is always a backlog of features to each project, and we try to release those features in bi-weekly code sprints. The purpose of each daily Scrum is to determine what each developer accomplished the day before, what they hope to accomplish today, what (if any) roadblocks might prevent that progress, and what is needed to resolve those roadblocks.
As these impediments to progress arise, the goal isn’t to solve them during Scrum. You don’t want to take up everybody’s time for that. The goal is to identify and clarify issues, then let everybody know what their role is on the project that day, and get back to work. After the meeting, the Scrum Master reviews notes from the scrum, and sets out to resolve any roadblocks.
There are plenty of days when there are no roadblocks. Widgets have been worked on, everything is fine, and progress is excellent. That doesn’t mean that a Scrum for that day is unnecessary. All information on the project is valuable.
Scrum, at its most basic level, supports the team player concept at work: to belong, to learn, to do, to create and be creative, to grow, to improve, and to interact with your coworkers. In other words, Scrum leverages the innate talents of individuals, encouraging them to do great things together.
Here at CommonPlaces we employ two different types of Scrum meetings which, I suppose, is quite uncommon in a lot of businesses. We also hold weekly Scrum meetings every Monday morning, in order to enlighten and inform the entire company on general progress and business. Because of the number of people involved, and the amount of information that’s parceled out, these company Scrums tend to last nearly 30 minutes. However, the value of keeping the entire workforce informed is immeasurable. No one feels left out, and everyone is offered an opportunity to ask questions and voice their thoughts.
How does your team operate? Do you employ Scrums to maintain the flow of a project, or do you utilize some other method? Post a comment, and let us know your secrets.
