FAQ
From Mp
Frequently Asked Questions
Why should I design a custom methodology when there are many that already exist and have been proven in many successful projects?
For a more detailed discussion on this, see the Why Design a Methodology article. Existing methodologies have been "proven through success" only because they have been successful on some projects. On others, they have failed. No existing methodology can claim "a perfect score" when it comes to success rate. Some of it has to do with proper execution, understanding, etc. In others, it was just not the appropriate answer to the problem.
Because of this, it's not about finding the right methodology, but designing and owning your own. Everything can be changed through process improvement practices. When does following an existing methodology stop being that methodology when you change some of the fundamental aspects of it? When you design your own, there's no need to worry about stopping this or that practice or starting another. Any and all practices are available for use when you design your own.
Should I design a methodology for each and every project?
Not necessarily. Typically, you'll want to design a methodology for the "smallest" organization that's appropriate. It doesn't make sense, necessarily, to design a methodology for each and every project because it's expected that most projects within an organization will be built based upon the same principles and parameters. However, if they change from project to project, then some ongoing tweaking will be necessary.
It's also important to design the methodology as close to the managers and staff executing it as possible. For example, let's say you have several hundred staff that work on numerous projects across many different technologies, interacting with many different business customers. Defining a single methodology across all of them may not be appropriate (then, again, a high-level methodology might be appropriate, with low-level details left up to smaller organizational entities). The reason for this is adoption. If a methodology is defined at a high-level within an organization, it may be difficult to gain adoption by all the disparate teams it's meant to affect. This is a fairly common practice for large companies with large IT staffs, and the result is typical failure of execution of the methodology across projects, losing efficiencies, causing chaos, and costing the business significant amounts of money.
Fundamentally, what needs to be done is what needs to be done. The idea behind designing methodologies is to take ownership of your own destiny and not lay blame on any particular tool or methodology that doesn't work properly. Spending the appropriate amount of time to look at your own culture to understand what can be done, what your want to be done, and how to drive that adoption and improvement over time will increase your odds of success more than anything else.
I've not designed a methodology before, so how am I supposed to create one?
To a certain extent, that's the reason for this site: to provide the education and library of patterns and practices from which to design and build your own. It's not a trivial task (nor is designing an enterprise system), but ignoring the need won't help deliver your software needs.
Also, if you're not familiar with methodologies, how would you know which of the many that are out there you should select? They all claim great success. None have "proved" total success, and all are meant to be tweaked and tailored.
Fundamentally, the problem remains, and the solution is learning, trial and error, or finding someone with the appropriate experience.
What if I don't design the methodology right in the first place?
It's called process improvement. When you design your own methodology, you don't care that you have to add, remove, or change a practice. You do it in order to be more efficient. As you learn more about how your people work, how your organization is run, or as things change, naturally, you'll find you need to make adjustments. Keep changing until you get it right (and you'll never get it completely and totally right, since many things are changing, more tools are developed, etc., but you need to strive for efficiencies because the opposite of efficient is not interesting).
How do I determine the principles that should guide the design of my custom methodology?
This may or may not be easy, depending upon the political and cultural constraints of your organization. In general, a collaborative effort is necessary to define those principles that are important to an organization. Principles may be values, philosophies, perspectives, or simply motivations of the organization. Ultimately, those are defined, whether directly or indirectly, by the leadership involved in the methodology design (and any political pressure placed upon them).
As opposed to fighting the culture or political nature of an organization, it's typically easier to define the principles surrounding that environment, and then showing the implications of what those principles mean. Interesting insights may be found from merely picking principles and watching the implications through practices selected. Remember that all practices should be mappable back to principles and the parameters of an organization. This can by very tricky when a practice implies a particular principle that isn't defined or wanted.
Ultimately, the idea is to define a small set (less than a dozen) of principles, get buy-in from leadership and the organization, and define them out as far as possible. It's not enough to say that you have a principle called "quality." What does quality mean to the organization? Are there a few sentences that help define it further, to make it less vague?
How do I determine the parameters that will constrain the design of my custom methodology?
Parameters are the physical, environmental, and business constraints associated with an organization and the projects it handles. Physical parameters may be the layout of the work area, or the fact that the team is co-located or remote, etc. It could even refer to issues such as a lack of conference room space, limiting how code reviews are performed!
Environmental parameters may refer to client needs, the type of team, technology, and tools available. Business constraints may refer to the financial implications of projects (i.e. are they firm, fixed priced, time and materials, etc.). Budgeting concerns may affect tools availability, etc.
In some cases, the political environment may have a significant impact, and may change over time. It's important to identify these types of constraints so that when they change, you're able to adjust for them. One practice that is being used because of the opinion of a particular leader may be dropped or altered if that individual leaves or changes positions.
Other parameters need to be taken into account of, as well, such as CMMI, ISO, and compliance requirements. These are all parameters that will affect the way software gets built. Simply brainstorming out these types of constraints is a good start. More than likely, not all of them will be identified, initially. Hence, process improvement is an important practice to ensure that as new constraints are identified, adjustments to the methodology are made.
Can I use tools to support my methodology?
Absolutely! If a tool provides business value (meaning, its value is greater than its cost), then, by all means, use it. However, it's important to perform a cost/value justification, because it may seem like a good idea on the surface, but ultimately be a waste. For example, defining value needs to be converted to dollars. Typically, this is done via time: average cost of developers (or other users) times the time saved. Cost, however, can sometimes be more difficult to quantify. The licensing costs don't tell the whole story. Training, complexity, support, etc. can all come into play.
Fundamentally, if a tool provides business value, a methodology should support it. This allows an organization to design their methodology and include their selected tools to support that methodology. Tool changes, then, become nothing more than process improvements.
