Software Development Methodologies, Part 6: The Unsuccessful Method

1. Introduction

There are several development methodologies and philosophies available to software professionals: extreme, agile, scrum, waterfall, to name a few…all of which are familiar terms to an experienced SDLC practitioner. When these methods are put in practice they often fail to produce the benefits advocated by their proponents.

The Unsuccessful Method (TUM) has proven, in practice, to have a lower barrier to adoption by the project team, to be easier to adhere to the standards and practices than other methodologies, and has more predictable outcomes than any other software development methodology that we are aware of.

2. Principles, Standards, Activities, and Practices

Typically, each word in the title of this section would be broken in to its own subsection, but the flexibility of TUM allows for just about any topic to be interspersed with topics that may or may not be relevant to the surrounding context.

2.1. Flexibility

The guiding principle in TUM is flexibility at all phases of the process and project. The lack of rigidity allows for pointless and arbitrary changes in goals and objectives and allows for assignment of personnel to tasks without regard to aligning skills required for a task to the actual abilities of resources. As covered later, this makes TUM methodology ideal for an inexperienced development manager.

2.2. Distributed Authority and Complete Lack of Accountability

Another key component of TUM is the distribution of decision authority across the project team. TUM software projects don’t have a software architect. By avoiding a central concentration of authority and responsibility the project team is free to make decisions about their involvement in the project without regard to other portions of the project. In essence each project member can be their own authority and pursue activities and objectives on their own timeline and set their own priorities. This feature of TUM also makes status reporting a breeze.

Total lack of accountability across the project team affords team members the freedom to choose to deliver assignments or not, and even move in and out of projects depending on their interest level. A side effect of not assigning accountability within a team is that deadlines become completely unnecessary when following TUM.

2.3. Arbitrary Order of Activities

In other development methodologies the order of activity plays an important role in the structure of the project, e.g., coding usually cannot begin until a data model that satisfies the product requirements has been developed. In keeping with the theme of flexibility, TUM doesn’t enforce any such order of activities; developers can start coding the user interface without any data model at all, and QA can begin developing test cases without ever having seen a requirements specification! Eliminating a strict order of activities has an interesting side effect: entire phases of a project can be avoided completely. This proves to be especially beneficial at the beginning and end of a project…those times, in other development methodologies, that activities such as difficult requirements gathering or QA testing would take place.

2.4. Design by Committee

Although it isn’t specifically listed as a principle, standard, activity, or practice of the methodology, TUM encourages fairness amongst all project participants: each project member has an equal and final say in the design of the software. Any software element’s design cannot be considered complete until the project team reaches unanimous agreement on every detail. Allowing everyone to have an influential voice in the project regardless of his or her experience or applicable skills protects them from hurt feelings or fear of another project member detecting their incompetence. Since an incompetent team member has just as much authority within the project as a competent team member, the effort required to disguise incompetence is considerably less than in other methodologies.

2.5. Avoid Involvement by Disruptive Stakeholders

Some of the most difficult and time consuming activities in other development methodologies involve project stakeholders who aren’t actual doers on the project. The classic example is user involvement. In other methodologies user involvement comes along at the worst time in the project: the beginning, the middle, and the end. Gathering requirements from users, finding out what they want software to do, vetting user interface design concepts against them, and having them test the system are all awkward touch points between project members and user stakeholders. TUM avoids these uncomfortable project interactions by prohibiting the involvement of outside stakeholders. Developers can simply define the requirements as they see fit, and test what and as much as they feel like. The time spent in meetings alone makes this principle an attractive one in TUM.

2.6. Small Unit Project Planning

The axiom, “failing to plan is planning to fail” is simply ignored in TUM. Creating a project level activity and resource plan is a difficult and time consuming task that forces project team members to think about their assignments in a great level of detail, break down work into measurable activities, and then estimate the level of effort involved in accomplishing those discrete elements of work. TUM avoids this arduous task by allowing for project activities to be planned on a day-by-day or even hour-by-hour basis. Even better, a project manager isn’t even required because the individual project members can do this autonomously. A follow-on effect of this practice is that re-assigning work within the project team can be done without regard to resource availability or level of effort required.

2.7. Developer Choice of Implementation Language

Another branch of the “flexibility” tree is that by following the TUM process developers need not be forced to utilize a specific language for their coding assignments. The lack of an architecture, coding standards, database design, object model, or implementation language allows developers the freedom to work in the language of their choice, perhaps choosing something “new and exciting” which can enhance their resume for their next job.

2.8. Post Project Budgeting

Who hasn’t been burdened with trying to estimate the cost of something that isn’t very well defined? The art of software estimation is the subject of many studies…and TUM makes it irrelevant. When following TUM the project budget is simply established at the end of the project, usually after the project is cancelled.

3. Benefits and Drawbacks

3.1. Repeatable Process with Predictable Results

100% predictable results…something that no other software methodology can offer. Not only that, but the results are easily replicated to all TUM projects.

3.2. Low Barrier to Adoption

The lack of rigidity, no requirement for discipline, and total abdication of responsibility within the project team make the TUM methodology one of the easiest to adopt within an organization.

3.3. Ideal for Inexperienced Managers and Developers

When following TUM managers and developers don’t have to actually know anything about software development. This makes TUM ideal for new managers and inexperienced developers alike.

3.4. No Deliverables!

Yay! It’s virtually impossible to get anything done with a steer-by-committee groupthink project mentality, so why not enjoy it?

3.5. Responsive to Rapidly Changing Market Demands

Most of us are familiar with the notion that market demands frequently shift, forcing realignment of objectives within an organization. Software projects that follow one of the traditional software development methodologies are typically geared towards delivering a fairly specific product and are not easily retooled to a completely new set of objectives without a significant amount of rework. Thankfully TUM has no such impediments. An attribute of TUM projects that proves useful in this situation is the fluid and often-immeasurable progress of any stated or perceived objectives. This lends itself well to rapid and arbitrary changes in the direction of a project allowing for a total redefinition of the product being produced with little or no affect on schedule. This last point is particularly attractive to upper management who will find that this methodology fits well with artificial and irrational deadlines, which can be imposed by management and accepted by the project team without any prior collaboration.

3.6. Can Create Small Amount of Staff Turnover

Alas, there is always some downside. Most of the experienced software developers that enjoy working with other smart and hardworking professionals will probably leave during a TUM project. Don’t fret…if you follow the TUM methodology enough times the project team will be have a healthy collection of success-avoiding incompetents.