By Corissa Niemann, October 25, 2017
Menlonians are often asked how our methodology compares to others in the industry. From Lean to Agile, we are known for borrowing the tools and practices that we find useful and making them our own. Over the past few years, Scrum has entered the conversation due to the many obvious similarities between that methodology and standard Menlo methods. So how exactly do the two differ?
Many of the differences lie almost solely in naming conventions. For instance, Scrum calls for development features to be broken down into manageable bits they refer to as "user stories," which are often captured on a sticky note or index card. At Menlo, we accomplish this same goal through "storycards." Each storycard refers to a user (typically our primary persona), their goal for the described functionality, and any additional relevant information. For instance, we may have a card whose title is "Kelly can view all her tasks for the day." In the body of the card, we would describe the functionality that Kelly expects, as evidenced by our end user observational data and design assessment feedback. The key detail for both user stories and storycards is that the task described is clear, concise, and estimatable. Other practices whose differences are nearly in name alone include Scrum's "sprint planning meeting" and "Scrum board". Both are nearly identical to Menlo's "Kickoff" and "Work Authorization Board” respectively.
However, we have noticed several key differences between Agile Methodologies and Menlo Practices. The first of these is project cadence. While Scrum teams traditionally have sprints that run for two to four weeks, Menlo iterations last only one week.
This practice grew out of a desire to remain in close alignment with our client."
Our team wanted to encourage regular, scheduled stakeholder participation so that even if our team and the client team somehow fell out of alignment, a week was a relatively short period to get things back on track. It's highly improbable that an entire project could be thrown completely off course in just five working days. We have, however, paired with Scrum teams in recent years and changed our project cadence to allow for two-week iterations. These "experiments" were in direct response to a stated client need and have been largely successful. Our team still advocates for weekly iterations, as we believe it allows for more precise planning, but we now offer two-week iterations when it’s a more fitting solution for the client project.
Another notable difference can be found in how we estimate storycards. Scrum calls for comparable estimation in "units," where each user story in the backlog (the full list of all potential user stories required to create the product) is compared to the other stories. Thus, estimates indicate how small or large a story is in relation to all the others. It is a wonderful tool for prioritization and to get the team on the same page with one another. In contrast, Menlo uses this tool with a small twist: estimates are given in hours, not units. We do this for many reasons.
First, hours are easily understood by all people involved in a project, from developers to clients to accounting departments."
We believe it is easier for our clients to choose which cards to authorize if they can see how many hours each one may take. Second, our team members can easily determine if they are on track for meeting their estimates. If a pair realizes they are going to exceed the number of hours they estimated for a given storycard, they can alert the project manager and adjust accordingly. This allows for some of the flexibility that Agile development is best known for. We acknowledge that estimating in hours is a more precise skill than estimating in units, and this is a skill we actively work to grow in our team. In our experience, it leads to more informed decision-making and more seamless planning.
Regardless if a team uses strict Scrum methods or alters them to fit their unique work environment, remember to keep the goals of Agile development at the forefront of any project: always involve the business and keep the entire team engaged. Don't create silos of knowledge and obstacles in the form of unnecessary handoffs. Learn from each iteration and adjust in real time so that project goals can be met. That's the true secret to Agile success.