By Alejandro Gomez (@zemogalejo)
How would you build a great product that responds to the rapidly changing needs of your customers and the market? Would you take your time, plan every detail meticulously and wait till all portions of the project were finished before you began testing? Or would you map out your goals, build individual parts of the project first, and constantly adapt your build to react to problems or changes in the environment that occurred while you were completing your development?
If you were a 14 year old kid impatiently waiting for a video to download, you would choose the second option. After all it’s the guiding principal behind BitTorrent. And surprisingly, if you were a best practices digital developer like Zemoga, you would choose the second option as well.
While perpetual Beta has become a commonly accepted practice in the digital world (think of how many years Google labeled Gmail with that status), the idea that projects wouldn’t be built as a wholly formed entity and then tested for quality and performance is a fairly new one. But as our industry has learned more about building products to ever tighter deadlines, an “agile process” has often been identified as the best practice for creating materials.
At Zemoga, we use a variation on the Agile Process called “SCRUM”. The name comes from an observation that the “relay race” model of building things, where one team hands the baton to another (that’s waiting to receive it) may not be the most effective way to create products. Instead, a rugby like model, where the whiole team advances the ball together towards the goal may be more effective.
How does SCRUM work? The two essential components of this development work are the SCRUM team and the “Sprint” meeting methodology.
SCRUM teams are typically small (7-9 people) and include all the skill sets required to take a feature or component from the idea stage through to a fully functioning, finished product. The team is self-organizing and cross-functional so the best people to solve any given problem will be assigned the task. Traditional roles, titles and bureaucracy have no place on a SCRUM team. In fact, there isn’t even a set team leader. Instead, the team is supported by a “SCRUMmaster” whose role is to coach the team and make sure they stay focused on their objectives. In Zemoga’s case, our Project Managers act as the SRUMmasters, ensuring successful delivery of identified products or tasks. The other key support person for the SCRUM team is the Product Owner, who represents business, customer and end user objectives for the product. Typically, our Client Services Managers fulfill this role on our development team.
The SCRUM team works in a series of time boxed iterations called “Sprints”. Sprints are phases of project development that are typically two weeks in length (although they can be as long as four weeks). At the start of each sprint the team identifies the features or products that can be developed within the timeframe of the sprint. At the end of the sprint, the deliverable is a fully functioning piece of software that could potentially go to market. The sprint process begins with a planning meeting but is really moved forward by daily sprints, short 15 minute meetings in which each member of the team reports on the work they have completed, their planned future work and any problems they’ve encountered. At the end of the process a review takes place, where the functional product is presented to the Product Owner and other stakeholders for comments and feedback.
Why do we choose to work this way? The main reason is SCRUM allows us to focus on delivering the highest business value in the shortest period of time. That means lower costs and better deliverables for our clients. It also allows our customers to rapidly and repeatedly inspect pieces of actual working software so there are no surprises when the final product is delivered. If changes are required, this process allows us be responsive. Since there are no set roles for the SCRUM team, it’s easy to identify the best people to solve any problem that may arise. Ultimately, SCRUM emphasizes individuals and interactions over process and tools, allowing better communication between us and our clients and making everyone in the process feel more involved with the final product.
Of course, it’s not just Zemoga using this process. SCRUM has been utilized by Microsoft, Google, Yahoo, Electronic Arts and many other leading technology companies. If you want to find out more about this methodology check out the following links:
How are you managing your project development? What do you think are the best methodologies for bringing digital products to market?