Agile, Agile, Agile. It's hard to disagree with a project management process named "Agile". It's like disagreeing with something named the "Patriot Act" or answering "No" to a department store checkout attendant that asks if you would like to save 20 percent on today's purchase. It's clear: Agile is cool, and every Scrum master certificate mill will agree with that statement.
But what happens when an Agile paradigm isn't appropriate?
"How is that possible?" says the guy with the skinny jeans and the PBR.
There are two scenarios where we think a more "waterfally" approach is appropriate (We'll explain the "more" part later... because no one could ever be purely waterfall if you think the name implies a rigid schedule).
The first is when a project is innately low-risk, and the second is when your stakeholder doesn't wholeheartedly buy into the Agile process. Examples of the second include Kickstarter and the majority of contract work.
For the first case, I think you can throw out any game development scenario where you are striving to achieve fun that isn't a full clone of something that is already proven to be fun. Fun is just too damn squishy, and in my experience, you don't know something is fun until you play it and say, "Hey, that's fun!"
Creating fun is a risky proposition. Vertical slices -- a technique where you make some small percentage of the game at near final quality -- and rapid prototypes help pave the way for a more structured project.
The second case is the focus on the remainder of this article. GarageGames is a service company and in the majority of the cases we see, the formula for customer's desire on an initial consultation is usually something similar the following:
I want X by the date of Y. How much will you charge me?
A customer wants a firm fixed price (FFP) quote for a game-related software development project. How does a company arrive at a price and date that is fair for the procuring and commissioned company?
To simplify the problem statement, what the customer wants to know is: What, How, When, and How Much is required. Additionally, you will need to determine Who from your firm will do the work. Those elements, solved together are a FFP contract, schedule, and Statement of Work (SOW). Here are the steps we use to build them:
- Determine initial scope -- Focus on the What.
- Determine if the project is suitable for FFP contracting -- Initial analysis of How.
- Build a rough order magnitude estimate -- Second analysis of How, first analysis of When and How Much.
- Determine scope of the Statement of Work -- Final analysis of What.
- Determine & deliver final quote -- Final analysis of How, When, and How Much and Who.
Determine Initial Scope
This usually occurs through one or more conversations with business development, technical, and project management. If a GarageGames employee can do all three it can often be covered in one conversation. The most important goal is to be output and goal focused. Don't get too caught up in implementation. Right now you are more interested in the what than the how or when. For us, this process of determining initial scope starts with a conversation about the customer's high-level goals.
Often times, the customer doesn't know what they want aside from their high-level goals; sometimes, you need to help them understand their goals (a bit of a red flag sometimes). It's understandable that they might not know; if they really understood the solution to their high-level goals then they wouldn't be coming to you now would they? Work with the customer to define and document the high-level goals. By understanding them, you are in a better position to either develop their plan or validate any existing plans.
Knowing how much can be helpful at this stage. Customers typically don't want to tell you their budget at this point because they are worried that you won't give them an honest quote --you have an asymmetric knowledge advantage that makes them uncomfortable. A customer's budget holds intrinsic clues about what can be accomplished and not knowing that number will make the process much harder to scope and define the project.
GarageGames asks customers to try and identify a budget range for the purposes of accelerating the quote process. We assure them transparency in our quote that addresses their fear and we've found that sharing more detail with the customer gives them a better experience. Transparency puts both parties on the same side of the table tackling a problem instead of negotiating against each other as foes. Working together to bring down cost is something we enjoy doing. We believe that if we save customer money they are more likely to spend that money on us in the future. Both sides win.
If they aren't willing or allowed to share a budget range with you hope isn't lost -- it's just more work to triangulate the cost from the bottom up.
Determine if the project is suitable for FFP contracting
At this stage, we are going to analyze the project by doing an initial analysis of how we will implement the project to meet the customer's high-level goals.
It's time to start thinking about risk. All projects, especially software projects will have some risk. How confident are you about your team's ability to accomplish this project? What is the variance of success and failure? At GarageGames we measure risk using a confidence scale of 1 to 10.
With an eye towards risk management, we do our initial analysis of how we will implement the solution. To do this, we work with technical leads to formulate an approach.
We decompose the output above from high-level outputs into smaller features. This process is known by many as a Work Breakdown Structure (WBS). At GarageGames, we tend to get to a more detailed decomposition than many. It takes more work, but it protects us from taking a job we can't complete by exposing more known issues.
For each of the features, we have the leads describe the expected implementations. How will you develop this feature? How confident are you that this approach will work? Document the confidence and determine a gut feeling about your confidence in the implementation of the entire project. A task estimate may look like this:
Implement Frustum Culling Estimate: 20 hours Confidence: 7
One of the biggest mistakes made by companies is saying "yes" to a job they can't perform. If your gut feeling is that you aren't very confident in your ability to accomplish the work, please do yourself a favor and either 1) walk away or 2) insist on a time and materials contract where you are paid hourly for the work as you accomplish. Saying yes to a FFP job you aren't confident in will likely hurt your business as bad as your prospective client. Just say no!
If you are having challenges decomposing the steps or the cumulative confidence numbers are low, this might be a bad job for your company.
GarageGames Confidence Scale
Below is the scale GarageGames uses as a standard for confidence numbers:
- No clue -- don't make decisions on this. We need to talk more.
- Hardly a clue -- don't make decisions on this. We need to talk more.
- Someone else has done this and I read about it; job not well defined -- don't make decisions on this. We need to talk more.
- Someone else has done this and I think I understand this; job might not be well-defined -- don't make decisions on this. We need to talk more.
- Done something similar to this before and this relates to that work -- this estimate has a variance of +/- 50 percent of estimate.
- I think I understand this fairly well and I understand the goal.
- The average case for programming when the requirements are understood.
- A confident case for programming; average case for a lot of art work.
- I've done this before and it's very similar.
- I'm probably not working on software... or... no matter what; I'm only going to work on this for a period of time (i.e. 1 week of QA).